DEV Community

Cover image for Back to Square One
Piyush Udhao
Piyush Udhao

Posted on

Back to Square One

"Shit.", I thought.

I was trying to sleep, tossing and turning in the bed, counting the sheeps of sleep. And then it hit me. The reason behind the growing unease and frustration I have been feeling while coding any project I take on these days.

opens a new tab
"ChatGPT", I type. In the prompt, I say "Write me a function that uses the <enter framework> API to authenticate a user. Write me another function that renders the exact type of button I want. Write me ... my entire project basically. And explain each line of code."

opens another tab
"How to code a <enter software> tutorial" or "<enter framework> tutorial", I type into Youtube. I click on a video that says "Build <enter software> clone in just 2 hours!". After following for a while, I find some syntax that I didn't quite understand.

opens yet another tab
"<enter language> tutorial", I now look up. I watch a tutorial that explains the features of the language for a while. I don't find what I want. "<my doubt> syntax meaning", I look up on Google. I read a few StackOverflow threads, but they don't apply to my situation. Since I wasted my time, I am now demotivated. I close all tabs, close my code editor (:wq 😏), and decide to take a break. I never come back from the break. The project sits unfinished; it will sit unfinished for god knows how long.

Problems, Problems and Problems

Our brains are fascinating, you guys. If I start thinking hard about what I want to do, how I can achieve it, a clear plan of action starts to form within seconds. A roadmap emerges from nowhere. A perfect sequence of actions that, if executed to the T, I will be successful.

With the goal of success in mind, I start traversing the roadmap. A few milestones are easily completed; creating the project, importing the dependencies, building the initial state of the prototype. And then, I start encountering potholes on this road I have taken (Robert Frost turning in his grave somewhere).

I either:

  • run into build errors that are obscure as 🦆.
  • find some aspect of the project to be quite annoying (cough, front end, cough)
  • combing through the documentation of a framework, trying to find that one function I need.
  • get sidetracked into a completely separate rabbit hole that ends up taking a whole day.

But most importantly, I:

  1. realise that I don't possess enough knowledge about the field to be building such a project.
  2. get confused about what the correct way of doing things are, the industry practices that my "personal" project needs to conform to.

Lack of Knowledge? Lack of Skills? Nah, just plain inexperience.

The first point really drives me nuts. I started the project in the hopes that I would learn the underlying concepts of development by building it. But during development, I find myself not knowing what to do next.

This helplessness leaves me no choice; I have to return to 👹 TUTORIAL HELL 👹. "How to do <what I want to do>?" I search. In the results, I find "Follow this tutorial to build <not exactly what you want but something close enough>!". The problem with most tutorials like these is that they tell you what to do, not WHY we do what we do.

What I've realised over the past year is that, understanding WHY some tech/framework/paradigm is needed is way more useful than understanding how to use that tech correctly. There, I said it. As an amateur coder, building software the correct way, the optimised to the moon way, is overrated.

I come across so many youtube recommendations like "You've been using <enter tech> the wrong way" or "How to build FAST and OPTIMAL <enter software> using <enter tech>". What I didn't realise earlier is that these videos aren't meant for me; they are meant for professionals who know exactly WHY wrong is wrong and inefficient is inefficient and can verify whether the youtuber is spitting fax or clowning.

I don't know why wrong is wrong. I can't verify what he's saying. Hell, I don't even understand half the terms he used to justify his way of doing things. Why?

Because I haven't gotten my hands dirty in it yet. I haven't made any mistakes to learn from. I haven't fully grasped how the tech that I'm using came into existence and what problems it solves. I just copied the best way they kept telling me about and moved on.

I realise that making a mess of your project is a canon event
in the early stages of becoming a developer. Maybe the end product is slow and unoptimised, but its still something. YOU made it. And nobody can take that away from you. You learnt about the PROBLEMS that you faced while building the thing, and now you can fully appreciate the tech developed to solve those problems.

What now, then?

Yay, I realised my pitfalls. What now? cricket noises

Having rethought my entire outlook on development for the better, I think I will start again from the beginning. From the absolute basics. Like C level basics, web tech basics. Basically, learning from the ground up.

But this time, I will try and wrap my head around why mankind decided to do it the way they did. What were the pros and cons of doing it this way? In this way, I want to explore and understand the building blocks of all major tech. I want to learn from their inspirations, and build amazing tech myself.

With this platform, I aim to document my journey from absolute noob to a bash-scripting, code-automating, nvim-using, 'i-use-arch-btw'ing god tier developer! I would love to connect and understand your opinions on my newly though approach. I would also greatly appreciate any writing tips, as this is my first attempt at writing a blog. Thank you for reading through my two cents. Ciao!

Top comments (0)