The Hidden Catch With Using Frameworks

Frameworks are fantastic ready-made tools that offer a wealth of functionality for building applications. However, there is often a hidden drawback to using them. In this article, I'll explain why I had to stop relying on frameworks and start thinking like a problem solver instead.

I have been a backend engineer using Python for four years and enjoy developing the unseen components of a system. It makes me feel like the character Elliot from Mr. Robot, which is quite amusing. During my early days as a backend engineer, I was quick to solve problems using Django. The framework had all the necessary tools to create a minimum viable product for a client, so there was no need for much thought.

I’ll tell you what happened. I got so comfortable with using the framework, and the ORM (god, so seductive) that I did not bother myself to understand the SQL operations it abstracted for me. A day came, I was working as a contract backend engineer, and the tech lead asked me a couple of simple, really simple SQL questions like:

• What are “Joins” in SQL?

• Why do we need “indexes”?

• How do you “select” and “limit” a hundred records from a table using SQL?

• What is the difference between “inner joins” and “outer joins”?

  
  

My heart sank. I could literally hear the voices in my head screaming “Oh, god. Oh, god. Oh, god. What do we do? What do we do now? Think, think, think, think!”. And after five minutes of an awkward long silence, he said to me:

“Abram… You are an amazing young engineer, and I am blown by your early exposure and experience you have in the industry. But if you do not know the answers to the questions I just asked you, then, that’s a very big problem.”

My so-called self-esteem and my knowing-it-all mindset got destroyed. I decided not to go ahead with building the project. I was depressed! And there’s where it hit me, just because you’ve successfully built and launched a backend system doesn’t mean it’s tightly secured, or that it adheres to principles that exist to govern the way you build systems. You need the know-how on how certain tools work underneath the hood. So, I did what anyone in my position would do, I began to study.

I refused to take up any contract, full-time or part-time role that involved me building projects that would be used by “real people”. I was scared something would happen. After six months of studying, and late-night brainstorming, I was confident again. I now had the confidence to build even more robust and high-performant systems without worrying that I was doing something the wrong way.

Whenever I am building an application with Django, I don’t say “I have designed the User and UserProfile models”, instead; I say, “I have designed the users and user_profiles table schemas”. The way I approach solving problems changed. I was no longer thinking in the “Django way” of doing things. I was thinking (literally) like a problem solver.

Summary and Parting words

At the end of the day, Django is just a tool for building software. So are Laravel, and NodeJS. You shouldn’t be obsessed with these technologies, someday they’re going to be obsolete. What happens then? Would you bitch around complaining? Or be a problem solver that can quickly adapt to the forever-changing industry?

I once was asked to work on X feature with Vue.js and I gracefully accepted the challenge. In less than 20 hours, I had read six (6) articles about/on Vue.js, read through important concepts I ought to know on its official documentation, and delivered the feature the next day.

Was I surprised I could pull off such a hat trick? No. Did I know I could do such a thing without no experience whatsoever? Why, yes. Of course! I am an engineer, and solving problems that would make my brains scream is something I love doing.