eureka - how to become competent in coding
As a pro beginner in coding and also an ideator, I've always been curious on how to efficiently build stuff that comes to mind with minimal friction or help within a specific range of time--because that is my new definition of competence in coding.
I think most of us (beginners - intermidiates) coders tend to fail at this because of our approaches. I'm guessing this is what goes on your mind when you wants to build a new project if you fall to this category (beginners - intermidiates)
oh i wanna build facebook (out of the blues cuz why not)
creates a repository on github
start solving bugs on vs code that i havent come across in my times of coding
somehow fix it (thanks to ai) , holly shiit another friction (how do i implement this next step
falls to delegating the crucial learning parts to ai (and succesfully accumulate tons of imposter syndrome)
eventually give up, holy shit i can build twitter (back to line 2)
Summary of what is actually happening above:
- you have decided to tackle to big enough for you an idea, such that in the process there is so many debts you have to pay at once, which significantly increases the chance of you not completing the project--even though you somehow managed to finish it, you'd have to re-implement lot of the new knowledge you gained in a new project so as to feel competent and less an imposter.
No shit sherlock, what should we do instead?
Well i'd say what we suffer from is competence[https://hassan2bit.bearblog.dev/competence-in-coding/], and experience beget competence, The professionsals are able to go far in a new project with less friction, and knowledge of how to go around in a (not so good) situation due to experience.
They've built tons of similar projects with similar frictions, which makes it so easy for them to be in control of any foreign situation.
And when you see them tackling a big project, what they are essentially doing is merging all these tons of previous experiences together and adding new sauce ofcourse.
Oh you probably go by holmes, what should we do instead?
As i have mentioned above, what we suffer from is competence, you are better off building 365 projects in a year instead of a single project that spans for months.
With 365 project:
- there is lot of time to re-invest, and new knowledge re-implement from previous projects.
- There will be little and manageable frictions
- you'd be familiar with lot of similar frictions (which will surely be very handy when tackling a bigger project)
- You'd have enough projects in your portfolio to boast mastery of a particular coding process or language
- you can easily do well in building a bigger project and man-handle any foreign situation you might come across due to lot of experience
I leave you to relect on building a single project that spans for months before completion (remember there is only 12 months in a year).
Surely there is nothing wrong with tackling project bigger than your current comfort zone, I learnt that it is recommended to also have that in place.
You should have lot of smaller projects and maybe 1 - 2 bigger side projects till you become a shark. But your smaller projects will greatly contribute to the effieciency of building your bigger side projects.
from one of your kind,
a pro beginner.