DEV Community

Cover image for How to Thrive as a Self-Taught Developer
Remus D. Buhaianu
Remus D. Buhaianu

Posted on • Updated on

How to Thrive as a Self-Taught Developer

You’re Great Even If You Can’t Center a Div

Your fingers hesitantly hover over the keyboard. The text cursor blinks. And blinks. And blinks...

Still, no lines of code cascaded down the page.

The stifling excitement you previously felt at the thought of finally building a head-turning project had vanished.

You rest back on your chair and close your eyes.

“It’s too much.”
“Let’s stop.”
“Give up.”
“Can’t do it.”
“Never will.”

You open your eyes. They dart to the clock on your screen.

It’s already been 30 minutes since you sat down. All you could muster up were 5 lines of code. Out of which, 3 were repeatedly removed and added.

You sigh.

“It’s just one of those days”, you tell yourself.

Yesterday was the same. So was the day before. Last week was no different.

Apathetic, you close your project.
“Not feeling it today. Maybe tomorrow”

You move on to Youtube. You look up your favorite content creators and hop in on another newly-released, hours-long coding project.

It’s pure perfection. Latest technology…eye-catching design..creative and smooth micro-transactions.

You click start. And so, your day was over. For the hundredth time.

This is the cruel reality of being a self-taught developer. We stumble and falter our way through the process; we get stuck in the same vices, unable to ever make any concrete progress.

Does this have to be the norm? Definitely not.

You can and will thrive as a self-taught developer.

Before we assess what we must do to thrive, we have to understand the process leading up to it and what obstacles prevent us from thriving in the first place.

1. Why You’re Stuck In Tutorial Hell

Tutorials have their place in your journey as a developer.

Through them, you gain easy access to systems, principles, patterns, and insights. Without them, you’d have to undergo a painful trial-and-error process to reach the same conclusions.

Yet, as with anything in life, if not done in moderation it’ll have a toxic effect.

The more extreme the indulgence in it, the stronger it holds you captive.

Hence why even the most prolific developers can end up trapped in tutorial hell. People who were once capable of blazing through complex and unique projects, now sit defeated in their chairs after 10 minutes of jagged code.

Tutorial hell sounds terrible, doesn’t it?

As it should - there’s nothing useful nor positive coming out of it. It only exists to fill your mind with self-doubt, frustration, and pain.

No surprise, then, that so many of us give up early on in our journey.

Although it contains the term “hell”, there’s nothing remotely religious nor mystical about its nature. Tutorial hell stems from human behavior and psychology.

That’s why you can escape tutorial hell. Once and for all.

After you understand where its power comes from, you can cut away its supply and strip it of its power definitively.

The Inescapable Habit Loop

Habit Loop and Tutorial Hell

The habit loop is what decides our future outcomes.

Whether we will find ourselves on a path of continuous growth or irreversible self-destruction, it all starts with the habit loops we develop.

Habit loops are our brains’ tools to easily navigate this complex world and save cognitive energy by automating behavioral patterns. If we had to make a conscious effort for every little action we take, would we have any energy left for the truly demanding tasks?

It’s thanks to this biological magic that hours can pass by you unnoticed as you watch “one last Youtube short”.

Although it feels like magic at first, breaking down the process will reveal why you feel powerless every time you attempt to break out of this accursed tutorial hell.

Here’s a breakdown in the context of tutorial hell:

1. Trigger

When you sit down to work on a personal project, without the aid of any third-party material, certain unpleasant thoughts begin to creep up in your mind.

“What if I get stuck on the first task?”, “What if it won’t come out exactly as I expect it?”, “Do I have it in me to build something like this?”

This trigger evokes a powerful emotional reaction.

It’s so powerful that you’re forced to take any sort of immediate action to ease, and even remove, the feeling of discomfort you’re experiencing every single second when you undertake a project on your own.

This is the stepping stone that paves the way to the next phase of the vicious cycle.

2. Behavior

The trigger puts you at a crossroads in the development of your habit loop.

Whichever direction you decide to take is what’ll determine the outcome of the habit loop; whether it’ll be healthy or toxic.

Unfortunately, the direction you have to take at this point is a no-brainer.

Because you find yourself wasting time and not achieving anything valuable with your project, you dash off to Youtube. There, you slowly slide down the rabbit hole for hours on end.

3. Result

The actions we take serve to fulfill an aim.

With each successful completion of any given action, we close the habit loop. A new iteration of the loop can safely occur again.

After embarking on a Youtube tutorial marathon, the goal was achieved.

The feeling of discomfort that haunted you had disappeared. You felt your time was used productively. More than that, you felt a sense of accomplishment at having built an entire project. (although it was a code-along from beginning to end)

Each time this loop occurs, you get more and more reeled in the pits of tutorial hell.

It’ll continue to reward you with a sense of accomplishment and growth. In return, it’ll increasingly demand more of your attention. You’ll need more tutorials to feel the same levels of accomplishment.

Therefore, not only it fails to offer any real value to you, but it demolishes your confidence as a developer.

Biologically speaking, the habit loop is not failing at all.

At its core, this loop serves as an aid to the brain’s two most important functions -> seek pleasure & avoid pain.

In other words, whatever behavior leads to pleasure and avoidance/reduction of pain, will always be rewarded and strengthened over time.

Next, we’ll look at how the tutorial hell is a coping mechanism and how understanding that will help you escape it.

2. How to Escape Tutorial Hell

To break free from the habit loop, and consequently, to break free from tutorial hell, you have to identify where these triggers originate from.

Although exceptions are found here too, there are two underlying fears commonly found in the minds of developers. From these fears, the tutorial hell loop pulls its strength.

They are: fear of failure and fear of boredom.

Fear of failure is an understandable fear, to whom many of us can relate.

We tie our self-worth to our ability to conjure up groundbreaking lines of code out of thin air.

Anything that fails to meet those standards is deemed an irrevocable testament to our incompetence as developers and our inability to succeed in this industry.

Anything short of perfection is not worth suffering through.

Yes, fear of failure and perfectionism are two sides of the same coin.

If we don’t have a safety net (tutorials) to ensure our perfectionism will be achieved, there’s no point in getting started with a project in the first place.

But this line of internal reasoning is itself proof why perfectionism, although idealistically perceived to be worthy of pursuit, is faulty at best and downright destructive at worst.

As incredible as the tutorials we watch might be, we fail to realize that there’s been an immense amount of time and effort behind the scenes to build this perfect, structured tutorial.

Trial and error were at the core of the project you sat through and coded along on.

Doubt and worry shadowed its creator every step of the way, but never overtook them. Why?

Because the tutorial’s creator acknowledged the fact perfectionism would have to be discarded and mistakes would have to be accepted. Not only that but to use those mistakes as stepping stones towards fulfilling the goal of completing a coherent, useful tutorial.

In that same spirit, you have to realize that whilst it’s important to be cautious and analyze possible outcomes, you’ll never have a definite outcome ‘till you start taking definite action.

*Fear of failing is fear of growth. *

Each project you tackle on your own is a chance to fail. This failure means you’ve acted towards a goal, but fell short of it. It’s here where most of us take this as some sort of divine or universal sign that we’re on the wrong path and we should turn around immediately.

But just as in a boxing match, you can parry the hit from this fear and counter-attack. All it takes is one question:

“Why did I fail?”

We tend to contend with the reality of the situation, never attempting to understand what led to it. Yet this process of self-assessment can turn the fear of failure into excitement to learn.

You wrote a function that failed the test? Perfect!

It means you tested one hypothesis. Now you can move to the next and discover whether your reasoning is correct or not. This develops your growth.

As stated before, there were two fears prevalent in the developers’ minds: the second one being the fear of boredom.

Fear of boredom can be elusive at first until we remember that part of the habit loop is not just avoiding pain (fear of perfection), but seeking pleasure in the easiest way possible.

Since you’re not making real progress by working on your own, your brain forces you to seek other ways of rewarding yourself.

Coding along on a tutorial is the easiest way in the habit loop to reward yourself. It triggers the release of serotonin (a feel-good hormone) which fills us with a sense of accomplishment and a feeling of growth.

You don’t have to sit patiently through hours of iterating over the same boring code. You can skip the whole process and reach the end part;

The need to quickly satisfy this need is so powerful that we dismiss the truth deep within us and continue to indulge in this toxic behavioral pattern ‘till we feel physically sick.

Just as we counterattacked the fear of failure, we can do the same for fear of boredom. It consists of turning around the whole narrative of this toxic loop.

Its current narrative is: “The journey is boring and therefore optional. The end is the rewarding part and therefore the only aspect that matters,”

That’s why you’ve not been able to sit through a project from start to end.

There’s no point in putting yourself through all the hassle if all that matters is just getting done with it.

Yet, that’s exactly what builds your competence and turns you into a reliable developer that can create value through technology.

Anyone can have a few glances on Youtube and copy-paste some code and call the project “done.” This behavior automatically sets us up for future misery and frustration.

Instead of aiming to “just get done with it”, so you can reach the finish line and get the quick release of serotonin, aim to be content with the journey itself.

Whenever you feel yourself failing to uphold a commitment to the new project you started, ask yourself this:

“Do I want to complete this journey for the sake of learning and growing? Or do I want to skip to the feeling of having accomplished something without having done anything?

3. How to Optimize for Consistent Progress

When starting as a self-developer, it’s incredibly easy to end up completely stuck early on.

This facilitates the creation of the habit loop that traps us in tutorial hell. We become unconditionally reliant on these tutorials to get ourselves unstuck.

When used wisely and sparingly, tutorials can aid you in your learning progress. But there’s a limit to how much they can teach you.
They’ll certainly never be a substitute for the wisdom you’ll gain from facing real-world projects head-on.

The issue is even then you can end up completely stuck.

The very tutorial that was supposed to help you break through the plateau and make progress is blocking the way.

Why is that?

Because regardless of how early or how far you might be in your developer career, your skills are all built on the same foundation: the basics.

Quick Mastery

6-figure salary, the ability to work full time from home and turn ideas into products?

That’s a powerful incentivization, don’t you think so?

It creates so much excitement around the prospect of becoming a developer that you should, no, you must become as proficient as possible in the shortest amount of time.

And so begins the marathon of tutorials, articles, books, and podcasts.

Throughout this speedrun where you can barely catch your breath, you aim to build a full-stack app within a month of starting on this path.

Perhaps you’ll rightly succeed in doing so. But at what cost?

In the frantic run to achieve “quick mastery” of these technologies, we overlook the basic notions. We treat them as mere trivialities that are optional and not a requirement before proceeding any further.

Since it’s basic, it’s automatically assumed to be boring.

Anything resembling boredom even in the slightest is not in alignment with the exciting prospect that a developer career offers.

But when your project breaks down and crashes your expectations, it’s usually not because the whole project is faulty. Often, it’s because a basic concept wasn’t adequately used in the context of your project.

You wreck your mind for hours trying to figure out where the error comes from, hurling your code in every direction possible in the hopes of a quick fix.

Whilst you can find a quick fix for the technical error, you won’t find one for the faulty logic that generated it, to begin with.

Therefore, when you find yourself stuck in a project and investing more time than necessary, take a step back. It’s a sign that you’re too caught up in the broad picture of the project and are overlooking fundamental concepts that are necessary to complete it.

A project, no matter how intricate it may present itself, will always start with the most basic of basics.

Familiarize yourself with these concepts. Synthesize them early on in your journey. You will save dozens of hours of unnecessary headaches and mindless scrolling through Google to search for solutions that you could’ve otherwise come up with on your own.

Hello World

Whilst the “Hello World” meme will never go out of fashion in the dev industry, it illustrates a fantastic point.

You don’t have to start big. You don’t have to make it shiny. You don’t have to make it groundbreaking.

It just has to work.

You don’t have to get it right from the get-go.

All you need to do is take the first action. Achieve the first goal. As insignificant of a goal as you may feel that it is, you’ve achieved it.

You didn’t fall into the clutches of self-doubt and fear of failing because you’re already building action momentum that’ll snowball throughout the entirety of your project.

This “throw it and see what sticks” type of attitude can be seen practiced frequently by artists.

Before starting with their actual paintings, they’ll do a warm-up.
Dozens of colors splattered on the canvas creating abstract shapes and forms.

It doesn’t matter how messy it is. It matters that they started.

They internalize the fact that the creation process and the learning journey are anything but linear. There’ll be deviations from the intended path at every step.

Due to their willingness to embrace this iterative approach, they go on to create exquisite pieces of art.

It could’ve never reached that level had it not been for breaking the biggest barrier: getting started. It’s never “How can I make sure to get it right from the get-go?”. It’ll only distract you from starting right now with what you already know.

Today, throw the code at the project. It’ll be a goofy mess.

How and why it works are of no concern right now. You’ll figure it out later.

Once you get in the flow of this approach, you’ll start to internalize it, and the stressful need to “get it right from the get-go” will slowly fade away.

When that happens, you can return and make it 1% better. The next day again. And the day after. And so on, until one day you’ll look back and realize this monumental project had started with an incoherent, cluttered mess of code.

Zone of Proximal Development

Zone of Proximal Development and Consistent Progress as a dev

Zone of Proximal Development was developed by Soviet psychologist and social constructivist Lev Vygotsky (1896 – 1934)

Previously, we covered why understanding the basics should be a high priority for you as developers.

Zone of Proximal Development puts this in the whole context of the learning journey and clearly illustrates why you need a balance to make real progress and continue developing your competence as a developer.

If a challenge/project you’re facing is way out of your current competence zone, your anxiety and frustration levels will match the difficulty of said challenge.

On the other hand, if the challenge is within or below your current capabilities, boredom will begin to settle in.

In either scenario, you’ll build a negative association with your coding experience. Then, it won’t matter how passionate you might’ve felt about coding because you’re left with no positive association.

This can increase the dependency on the tutorials or lead you to quit your journey in its infancy.

Therefore, it’s essential to build and maintain a balance as you continue to advance in your coding journey.

Here’s how you can build that balance:

  • Assess your current skill levels; be honest and realistic
  • Track the amount of time and effort invested per activity
  • Break every project into logical, chronological steps
  • If a project is too difficult, reduce its size/scope
  • If a project is too boring, test yourself by adding interesting features
  • Document what went wrong, what could’ve been done better, etc
  • Ask for feedback at every step of the way
  • Share experiences and knowledge in your own words

Conclusion

Being a self-taught developer poses a lot of challenges.

It requires a lot of continuous self-assessment, perseverance, and eagerness to make mistakes and learn from them.

It might feel discouraging at first and I understand you.

Each of these challenges feels like a mountain you’ll never be able to climb to the top of no matter how much effort you might put in.

But all three of them are closely tied.

Once you make a breakthrough in one of these areas, the positive effects will echo throughout all the other areas as well.

Tackle it one at a time.

Celebrate each win, no matter how small it may be.

Your thriving as a developer is not only possible but very much needed and wanted. You have a lot of value to offer to this industry and the world.

That’s why, to achieve that, you have to commit to escaping tutorial hell, building your confidence as a developer, and achieving the balance that’ll ensure your continued progress in your journey.

It can start today.

The day will come when you’ll look back and those unsurmountable mountains will be mere hills.

Reference

Habit Loop Image
Zone of Proximal Development

Top comments (0)