The Curious Case of Frameworks.

There are many times in my job as a web programmer when I realize, I don’t really know my stuff.

That sounds like a dangerous statement to make, since if one admits he doesn’t know his stuff at work, then he’s essentially inviting his employer to dismiss him, or potential employers to reject him.

That’s the thing about this profession: you don’t have to know your stuff completely in order to get things done. Completely being the operating word here of course. In the world of web programming, many of the really useful tools are free for grabs on the Internet. In order to finish a taxi hailing web app, for example, I don’t have to write all the code. Instead, I’ll probably grab the open source code from Google for the maps, another free tool for laying out content, and a few dozen more free packages that make my programming faster and easier. As long as a programmer knows how to put all these frameworks (essentially collections of reusable code, often free for all to take and contribute to) together and build something with them, he’s got things done, and he’s useful to his team.

As you can imagine, though, many web programmers won’t know how to write all those frameworks from scratch, since most of the time they’re busy learning how to use them. If you’re not in the industry, you might think, big deal! A carpenter doesn’t need to know how to build a hammer in order to use it.

But programming is different.

In fact, it’s so different I don’t know how to use an analogy to explain the situation. Instead, let’s imagine a group of elites at the top of the programming world, who spend all their time writing frameworks for the rest of the world to use. (Completely untrue, of course, but for the sake of argument please bear with me.) Then, at a level below them, you have the average programmers who spend all their time learning how to use these frameworks written by the elites. That is to say, there are the makers of frameworks, and then there are the users. The users are totally capable of using frameworks written by the elites to build stuff, and in fact they’re strongly encouraged to do that, since it’s inefficient and painful to reinvent the wheel. But the makers of frameworks will always be the most appreciated ones, since they’re writing code people around the world use, and that implies stronger programming skills.

So when I said I don’t really know my stuff, what I meant is that I don’t necessary know how to write the framework I’m using at any point in time. I.e. I’m the average programmer.

In reality, of course, there’s no clear distinction. The line between the “elites” and the “average” is blurred, and the “average” programmers contribute to frameworks as well, though maybe not as prolifically. And though I say the average programmer “use” frameworks, they’re actually also writing code in order to piece the different frameworks together. Only the people who write the frameworks tend to have stronger fundamentals, because strong programming fundamentals are necessary to write frameworks from scratch, as opposed to simply piecing them together. But I dare say that one can generalize and split web programmers (roughly – very roughly) into these two groups.

This leads to a very interesting situation when it comes to hiring.

Firstly, companies, especially top companies, tend to look for programmers who can really code. That is, they want to look for the elites. Of course, there’s a limit to the number of elites on Earth, so at the very least, they think, let’s look for someone who’s either an elite or is very close to being an elite. Thus, they want to look at the frameworks candidates have written or contributed to, and they want to test these candidates on their fundamental programming skills. Totally understandable, of course.

Here comes the problem: plenty of programmers, especially the new ones, are trained to learn how to use frameworks, rather than to write them. When looking through job descriptions, these programmers invariably see companies asking for people who know how to use Frameworks A to Z. Naturally, then, the job seekers will spend all their time and effort learning these frameworks, neglecting the fact that when it comes to the interview, companies will go,”Alright, now let’s see you build some stuff, without using any framework.” And if they fail to do that, they’ll be rejected, on the grounds of “insufficient technical knowledge”.

A very strange situation, no?

This applies not just to newbies, but also to programmers who spend most of their time at work using frameworks rather than writing them. These hardworking, conscientious professionals spend all their working hours learning how to use the free, popular frameworks to create a good product for the company, yet when they try to look for another job, they suddenly realize all those skills are now useless (at least during the interview), since they are then instructed to write code that tests their fundamentals, which won’t be as strong now since they had spent much of their time using frameworks instead of writing them.

In short, we want professionals who know how to use frameworks expertly, yet when we’re hiring, we test candidates not based on how well they use frameworks, but based on whether they’re capable of writing them.

I’m not so much complaining here as I’m feeling sorry for the professionals who are invariably confused (that includes myself). Once, I interviewed a young candidate who’s just graduated, and who wanted to join the team as a frontend developer. Naturally, I wanted to test his skills, so I asked him to build a really simple layout, just a text label, a text input and a button on a webpage. With nothing but a text editor and a browser.

Guess what? He didn’t know how to do it. The only way he knew, and was taught to layout things, was via Bootstrap, and without it, he didn’t know how to layout anything. He was an earnest and enthusiastic guy, but I really couldn’t accept a candidate who couldn’t write basic CSS code. Yet when I made the decision to reject his job application, I felt sorry for him, and hundred of others like him. It wasn’t his fault that he didn’t know how to write the CSS code that Bootstrap was build off; he was just a victim of circumstances. For someone like myself who learned CSS near its inception, I’d have the confidence to write Bootstrap if given the time and resources; not so for the aspiring professional whose main exposure to styling is through Bootstrap’s interface.

If there’s one advice I can give to these newbies, and to professionals who are confused by this situation, is this:

Learn how to write frameworks before learning to use them.

By this, I don’t mean we have to start rewriting frameworks from the ground up or even read through the entire source code before starting work. By the time we’re done – if that’s even possible – we will be dead from unemployment. What I am suggesting, however, is that we understand the principles and foundation behind the frameworks we use, and be confident enough to say, “Yeah, sure I won’t rewrite XYZ, but I kind of know how it is build, and can, if absolutely necessary, build it.”

Even now, for example, I don’t feel confident enough to say I can build jQuery from the ground up, because jQuery was the first (abstracted) form of Javascript I learned, and was my foundation. I lack the knowledge of the different design patterns behind it, and I don’t know the DOM well enough to implement it. I do, however, intend to spend some time understanding design patterns and getting a sense of how jQuery might be built without going through all the code, and to have a more intimate knowledge of the DOM. It is tough work, but absolutely necessary, because the choice of frameworks will change with time (right now, jQuery is sort of like the abandoned child of the industry), but foundations won’t. And as long as you get your foundations right, you will always be able to grasp new frameworks more quickly, and—from a more pragmatic perspective—find employment easily.

So if you’re a newbie and you think the hurdle is too high for you to get your first job, or if you’re a professional like myself who performed poorly in your last interview, remember that most of us ain’t competent with everything. Some of us are less confident with Javascript, while others avoid CSS like the plague. And all of us certainly don’t and can’t write every framework that comes our way. That’s fine—I think. The key here is to 1. get things done, and 2. keep building on our foundation, so that one day we will be able to say, “Now I believe I can write all the frameworks I’m using right now, even if I won’t need to.” And that’s surely an indication of us becoming a skilled professional, if not an elite one.