Frameworks in Perspective, redux

Back in 2015, I wrote a piece titled Frameworks in Perspective. My opinion of frameworks has not changed all that much since, though it's admittedly mellowed a fair bit after the rather juvenile rant I posted. Two years have passed, and I've had the benefit of a little more perspective.

You see, back then I was fresh off working under a Manager who was evangelistic about using frameworks. But it was hard for me to respect her style because she used them even for the smallest projects. The time she spent didn't seem appreciably less than the time it took for me to churn out code without using frameworks. And the aggressiveness with which she pushed her favorite framework, CodeIgniter, only served to turn me off it, and off frameworks in general.

Old-school is old-school.

A year later, I was out of that company and working under an old-school Manager who didn't use frameworks. In fact, he was so old-school he remembered dealing in magnetic tapes and COBOL. His code was VBScript in classic ASP, his lovingly crafted system honed through many years of changes and extensions. He did not believe in frameworks. He considered them clunky and ungainly, wasteful of system resources and not worth the time to learn. If he needed to write a UI, he wrote HTML and CSS the old-fashioned way. If he needed scripts, he did pretty much the same thing. His attitude towards the cloud was similar.

I liked this guy, and I had to acknowledge his obvious years of experience. Still, as time went on, I found his aversion towards frameworks stifling. Here was a guy, I realized, who absolutely needed to stay in this company because most other companies out there would find his skillset obsolete. And I resolved not to turn into him. Not because I didn't respect him - I do, he's a stand-up guy who takes care of his subordinates - but because I value my professional autonomy and refuse to allow it to be compromised by attachment to any one company.

Extremes

What was the difference between the first Manager and the second? Both harbored extreme attitudes. One would use only frameworks (and I suspect she was incapable of working any other way) and the other would never use frameworks. In my humble (or not so humble) estimation, they are both wrong.

In my line of work, you do whatever it takes to get shit done, by any means necessary. With or without frameworks. There is no only or never.

What's changed?

I've learned to use Bootstrap. I've picked up jQuery Mobile and AngularJS. For the past six months, I've been using Semantic UI and MeteorJS. Recently, I've even begun exploring CodeIgniter again. Basically, my aversion towards using frameworks has softened considerably in the past two years. I have gained an increased appreciation of how frameworks make life easier, especially for large-scale projects, and small-scale projects with plans for expansion.

It's also a matter of pragmatism. If I'm coding for work, whatever will get me the fastest results in the least amount of time, gets the nod. If that involves using frameworks and libraries, so be it.

I used to be really hung up on wastage. To me, every line of code in an application needed to serve a purpose. Frameworks and libraries ran counter to that purpose because they provide tons of functionality that any given application is unlikely to use 100% of. But now... meh. Given that roughly 90% of the web is like that now anyway, obsessing over wastage seems a tad pointless.

What hasn't changed?

I still don't think taking short-cuts without understanding the nature of those short-cuts, is the way. At least, not for a tech professional.

Technology has evolved, yes. A layman, for instance, may now create websites via Online Website Builders such as WiX, SquareSpace or Weebly without knowing a lick of HTML, CSS or JavaScript. I am a web developer. I can use those same tools to build websites, but not knowing HTML, CSS and Javascript is a luxury I don't have.

And any developer who uses frameworks without understanding what that framework does for them, isn't that much different from a layman in that regard. The typical web framework automates tasks like routing, sanitizing input and guarding against security threats such as CSRF and SQL Injection. I would find it alarming if a developer used frameworks without understanding how to implement those things without frameworks, or, in some cases, not even knowing what those things are!

I think of using a framework as akin to driving a car. The objective is to get from Point A to Point B, in the shortest time possible. Knowing how to drive a car is good. Knowing how to drive a car but not knowing how to walk (not really possible, but it's just an analogy)... not so good.

Point A to Point B.

Of course, at work, nobody has time to wait for you to walk from Point A to Point B. Of course they'd prefer you to drive. I'm not saying that frameworks are bad for business. On the contrary, they're excellent for business. They're only bad for developers, unless said developer has a rock-solid foundation to fall back on.

Just to be clear, I'm not expecting praise just because I can get routing up without relying on a framework. That's the bare minimum. Expecting applause would be like a database administrator wanting accolades for knowing how to write Stored Procedures!

Tool-user vs Tool-maker, a question of expertise

I found this blogpost particularly poignant. This is not to say that developers should have the skills of tool-makers, but rather that they should have a better appreciation for what those tools accomplish on their behalf. If a developer is going to use tools without learning at least a little about what goes under the hood, there is little point in calling them developers. The same way it is really hard to consider a guy a web dev simply because he can make a website using Weebly.

I've tried to bring this point across. I was met with disproportionate outrage from places like Facebook (nothing new there) and Quora (trust me, despite the BNBR regulations, many people still manage to be snarky and condescending... not that I have a leg to stand on). I had fellow geeks up in arms, nerd-raging and throwing clichés like "Standing On The Shoulders Of Giants" and "Reinventing The Wheel" at me, like it was going out of style.

What's next? "Don't Repeat Yourself"?

Dudes, dudes. I've heard this all before. Why is this even a point of contention? I agree. Frameworks are there so we don't have to re-do all the work someone has already done, and focus on doing new stuff instead. Yes, I get it!

But how can we consider someone expert on any given technology when all he does is use tools that leverage on that technology? We can't, and I include myself in that assessment. But here's the thing, and this may seem a bit outlandish to some...

...it is entirely OK not to be an expert. Not an expert, but just a tool-user? That's perfectly fine. Just because you're not an expert doesn't make you a bad person, a terrorist or a televangelist. Besides, expertise exists on different tiers.

Businesses often say they're looking for experts when hiring, but what they really want are people who can get shit done. They don't know, and probably don't care, about what goes on under the hood. They're laymen, for Christ's sake!

Results vs Process

Sometimes the whole thing about using frameworks just boils down to this - results vs process.

If your organization tells you they need a responsive website, they don't care if you use Bootstrap or Semantic UI, code it the hard way, or ask your dog to do it for you. They just want a result, and they want it yesterday.

OMG Fifi, you're a genius!

On the other hand, if I'm doing stuff for myself, I should feel free to take as long as I want. The result does not matter. The process does. If, for example, I go for 20 laps in the pool, I'm not going to do the butterfly stroke just so I can complete the 20 laps faster. No, I'm going to take my own sweet time and slowly breaststroke all 20 laps. Enjoy the process. This is not work for me. I'm a web developer enjoying a leisurely swim, not an Olympic athlete!

In other words, your employer pays for your time, so make that time worth something.

In conclusion...

I still have nothing against frameworks. Properly applied and in the right context, they can be a huge boon. The only point of contention appears to be - what constitutes the right context?

But that's for another day, and another time.

Non-expertly yours,
T___T