After being a part of the developer hiring process for a while now, I have begun to see what distinguishes an exceptional web developer (the ones that get hired faster than we can even make an offer) and everybody else. Things have changed since 1995 – web development requires actual knowledge of programming!
The problem is that people think web development is somehow easier than other types of development. Nothing is inherently easier about developing an application in PHP than in C++. While I could accuse people who say this as being naive, the truth is that web developers themselves seem to hold this as the truth. In order to excel at being a web developer, one must understand how to develop an application. In other words, there are very different skills required in programming something like Facebook or Digg than for updating Mom’s store website.
First, you must actually understand object oriented programming (OOP). Everybody these days says they “know” OOP. I don’t mean “you read about it in a book” or that you can use a class when necessary; I mean being able to write extensible, modular libraries. This takes time and practice. When people first begin writing classes, they mistake the process for “grouping up functions under one class name in one file.” This is dead wrong and actually counter productive in some cases.
Classes are about automation and simplification. The classic analogy for OOP is a car because it has many parts that make it a whole. But just like the driver has no idea what a crank shaft, piston, or fuel injector does, people using your class should have no idea (nor need to learn why) about the inner workings of your class. All they need to know is that calling one of the few public methods (turn_ignition(), step_on_pedal(), steer()) does a whole lot of cool stuff behind the scenes that makes their life easier. And just like how you wouldn’t want the entire car engine welded together (instead of using bolts and screws), you shouldn’t write humongous class methods that do 1000 things — break it up into digestible parts so that other people can enhance just the pieces they want (see “overloading” below).
When you design a class, you start by listing out things that the class will be used for. Then, you figure out the lowest common denominators between these actions to remove “special, one time cases.” You now have a list of your primary public functions. Everything else in your class should pretty much remain protected or private (discretion is learned with experience). The entire point is that classes are not a group of similar functions, but rather a single conceptual unit.
And when you’re all done with understanding why object oriented programming exists, you must then learn to use Inheritance, and Overloading (some languages) and Interfaces.
Second, you must understand and demonstrate competency with design patterns. At the very least, you should be aware of the Singleton and Factory patterns, which are very commonly used, and for (arguably) good reasons. Knowledge of basic design patterns goes a long way because a time will come when you may need to borrow from one of these concepts when developing your web application. It also means you have a wider exposure to the different types of architectures available to someone writing a library or application.
Last, you must understand scaling issues in growing web applications and how to resolve them. This is probably the rarest trait, but if you have it, you will shine like a rock star. It is important to realize that certain operations are much more costly than others. In today’s world, the CPU is rarely the bottleneck, but there are still bottlenecks. A common instance of this problem is when Word Press blogs go offline because it is slammed by a spike in traffic. That said, the most common type of bottleneck involves the database and often manifests in one of three ways:
- Each query sent to the database involves some small amount of lag between the web server and the database server. Hundreds of queries on a page will slow down your page loads. On high traffic pages, one less query means thousands of queries a second. Make sure you learn how to do JOIN statements.
- Each query must use an index in the database. Without this index, a query looking at a large table will bottleneck the hard drive (because it has to search large portions of the disk). Learn how to use the MySQL command: explain.
- Database tables using MyISAM (instead of InnoDB) risk facing table locking issues. When you run a big or complex update on MyISAM, no other updates can occur on that table until the first one is done. If that table is very large, this may mean someone’s page sits there and loads for a long time (or times out). Typically, one should use a transactional database such as InnoDB.
Other types of common scaling issues are:
- Session management on the database instead of letting PHP handle it. This is an issue because any large web application has more than one web server which means when a person hits a new page they might be loading from a different web server each time.
- Managing files generated on the server – such as when a user uploads a file. The issue here is that if a file is created on one server (in a cluster of 100), how do the other servers know it exists? Obviously the solution is to somehow centralize this with a synchronization process or store all of the files somewhere else.
- How queries can start acting different (much slower) when your tables reach 1M+ rows without proper precautions. Larger tables change things because indexes sometimes stop getting used or slowness that wasn’t apparent before is now very noticeable. (A book could be written here…)
Merely reading and understanding these issues has put you ahead of a bunch of people out there. 🙂
In conclusion, you must re-think the “web developer” as an application developer that happens to work in a browser. I often hear the excuse that these types of advanced concepts can’t be readily applied in small-time applications (such as a simple store-front), but I believe this is simply not true. Virtually every site requires a database connection or a template system (for easy inclusion of header/footer files). Database abstraction and template systems are probably the single best place to use OOP concepts. It simply makes no sense that one would use the raw mysql_query() function in any website, even if it’s just Mom’s baby pictures. Putting these ideas in classes reduces security vulnerabilities and makes development much faster. If the notion of abstracting templates or databases is totally foreign to you, I suggest you start by looking at Smarty or EzSQL.
Happy studying. 🙂
Michi Kono's Blog 
excellent article, as usual 😀
Interesting.
I have to disagree with you from a purely semantic standpoint.
Web developers produce web pages… simple, plain ol’ HTML web pages. These days, we’d likely call them designers, but using templating tools like Dreamweaver, it is easy to create an entire multi-page site using only HTML.
Web-app developers produce programs (in whatever language) that produce HTML, and this I think is the difference. People often don’t make that distinction, and I think that is what could lead to someone thinking that web-app developers aren’t ‘real’ programmers.
Like you say HTML is the ‘view’ to the web-app, but that doesn’t mean that there needs to be a program generating it.
Just my two cents.
Marcus: see, that’s the problem. Right there, you’ve already boxed in PHP development as some kind of smart wrapper for making HTML code. Characterizing PHP like that is about as fair as characterizing ASP as a drag and drop language (it is not). Developing the view (HTML, or whatever other front end) is a small fraction of the time spent designing a web application. Web development is about the *application logic*, which is why writing good web applications requires a broader perspective. For example, crappy HTML can be re-done very easily if a good MVC approach is taken to development, but bad application design will screw both the backend and front end from easy maintainance or upgrades.
Are you talking about web development or PHP programming? I don’t see why OOP is so important. In fact, I’d say the best reason that someone should know OOP is so they avoid overusing classes when they aren’t really the right way to solve the problem.
Same for design patterns, in fact Singleton is one of the most abused patterns and I’d argue is a poor pattern in a web app since it promotes use of global state which is antithetical to stateless HTTP.
I would say the ingredients to _most_ good web apps today are knowledge and experience with a 1) a SQL database, 2) HTML, 3) CSS, 4) JavaScript (or a JS library) and 5) a useful, general purpose language that can tie everything together. I use Python, but whether it’s C++, C#, VB, Java, Ruby, PHP, Perl, LISP or any other language, you need to be familiar with the different layers of the application stack. Knowing OOP or what a Factory pattern is not even on the list, IMHO.
i dont want to start a religious debate here, but I mentioned singleton because it is a very popular pattern that one should recognize has uses – and it does, whether it is over used or not. However, the point was that knowledge of different patterns is important to know and disagreeing with that point makes no sense.
The problem is that until you are exposed to a fully OO development environment, it’s hard to see what the big fuss is about. It’s like those people who still use perl and say it’s the most powerful web language. It’s great if you aren’t working in a team and have no plans to ever upgrade the code (i.e., never), but otherwise OO is the way to go, regardless of what language you are using. I’d argue that even if you are working alone, it’s foolish not to encapsulate application logic into classes, especially things like database, template, or session functioanlity. Even major JavaScript projects these days are all OO centric.
Your laundry list is basically “to be a good web developer, you must know all of the involved languages.” I am not disputing the requirement of knowing SQL or JS as those should be obvious. It’s *how* you use these technologies that I am pointing out.
I think overloading and overwriting are different things.
You overwrite a method that’s already defined in a superclass.
But overloading is when a class contains multiple methods whose signatures differ only by their parameter types.
This applies at least in the Java -world, AFAIK.
true, but in php, that is actually frowned upon (in strict mode, doing that type of overloading will cause notices). good catch! 🙂
(my readers are PHP coders, so I try to stick to that paradigm)
I don’t believe that I said word one about PHP. I don’t care what language you are working in the main differentiator of a web-app is the web. But then again, I have yet to see any non-web PHP apps that are widely used, so this is particularly apt for PHP. The main interface that the user operates with in a web app is program generated HTML code (and probably javascript, but that’s a bit different). I don’t think that saying that is a knock on anyone. If you don’t generate HTML code that is delivered over HTTP, you aren’t writing a web-app… so in this regard, PHP is really only used for web-apps.
My point was simply this: you don’t have to program to be a ‘web’ developer. Being a web developer implies that you can create HTML pages (Not-PHP pages). This could be done in notepad, with just a knowledge of HTML.
However, you do have to be a good programmer to be a good ‘web-app’ developer. The _app_ being the key part. In case this wasn’t clear: this was the semantic difference that I meant when I said I disagreed for a semantic reason. Web-apps are no different than any other application in this regard… you have to know what you’re doing or you’ll end up with a jumbled mess of code. On this I think we agree… I was just trying to point out that you don’t have to write an ‘application’ as a backend for a web site (and therefore be a ‘web’ developer).
Marcus – Your point really does seem to come down to a difference of semantics. HTML is basically analogous of a GUI. Would you call someone that designs a GUI a software developer? Probably not. By the same token, I wouldn’t call myself a web developer if all I did was write the GUI and no backend logic.
I think it’s pretty clear through the context of this post that we aren’t talking about making a web page with notepad or a WYSIWYG though. We’re looking at actual software design that is built to use HTML as its GUI.
I dunnno, Ben… You should check out the really cool database abstraction class I wrote in pure HTML. 😛
The word developer implies you write logic to manipulate data. The word designer implies you write logic to make things look good. If you are a web developer, you are one who creates logic to manipulate data across the internet. An application developer is one who creates logic to manipulate data on the desktop and/or internet. Writing some HTML and coding some CSS does not make you a web developer. However, writing PHP to output the HTML does, albeit, a low lever developer.
@Michi – Good article, I think most of what you say holds true.
@Marcus – Sorry bud, but I think you took a left somewhere when you should have taken a right. What is your background anyhow?
For those that agree (and I certainly do), perhaps you should take a look at a C++ GUI web toolkit to build web applications ?
Using Wt, you can skip all the CGI/forms/javascript/ajax/html jungle and instead go about a GUI application like you were used to (on the desktop).
See: http://www.webtoolkit.eu/wt
Regards,
koen
I think a web developer has to be an application developer and more. They need to know how to program in order to construct the server side code, then they are also required to know the client side aspect of it (html, css, javascript) which can be very challenging. In my experience application developers make lousy web developers and web developers hate doing application development.