Why so Many Developers Quit Before Ever Getting a Job. Please — don’t.
“Prototypes, objects, algorithms…those small steps between steps you don’t know how to implement.
Grrr…thinking like a programmer.”
Finish this sentence:
My last coding session was…
- Smooth as silk. I sat down comfortably, fired up my editor and dove into the lovely world of 0s and 1s. Those 3 hours passed like 30 minutes!
- Sooo boring. I barely forced myself to sit down and code. Nothing quite worked very well, errors were popping all the time and still not everything makes sense to me. These 30 minutes felt like 3 hours!
My guess is answer #2.
And not because it’s so common and also has happened to me (even after 8 years of programming).
Answer #1 is weird. Who even talks like that?
Ok, ok. We’ll talk about overwhelm in programming. I know we’ve all been there — it happens way too often and we hate it.
But I tried to go deeper.
Over the past few years, I’ve dealt with plenty of junior developers. Including some who:
- Recently broke into tech and felt lost
- Got stuck in the “tutorial phase” and cringed every time they had to code without supervision
- Were actually talented but failed at interviews or never even got a call
Where is the breaking point?
As the essence of my work is helping new developers find a job, I took the time to study their problems and really try to empathize with their needs.
I talked to colleagues at my company. I researched Facebook groups, forums, Q&A websites, huge Reddit threads and even surveyed a couple of small communities.
Here’s part of what I found:
“I felt like I just copied what was in the videos and that was it.”
“I have to make do with googling for existing examples that someone else has already written. I feel like a 3-year-old trying to solve calculus puzzles. It’s so frustrating.”
“I just can’t think like a programmer.”
And my favorite one:
“This is what I’ve learned about learning to code: You feel confused and completely unworthy like 99% of the time. But that one time you make something work, it’s MAGIC.”
Do you notice something?
These people’s struggles do not come from a lack of effort. Neither from a bad learning strategy or bad discipline.
They simply don’t have enough experience.
Yet, many of those people were on the verge of giving up programming.
What it boils down to — Two myths
I found that at the bottom of most struggles newbie developers face lay two popular myths about careers in software development.
I want to break them right now and hopefully avoid the overwhelm and extra pressure they cause to learners.
Myth #1: If you don’t love programming, it’s not for you.
This is something I hear newbie programmers say a lot.
And I absolutely disagree.
No, you don’t have to love programming to become a programmer. In fact, over 50% of professional developers sometimes hate it (my personal observation).
See, it’s nice when you solve a problem elegantly. It feels good when your code is neat, clean, well-tested and solves people’s problems.
But that’s not 100% of the time — not even remotely. Most working days of programmers don’t pass by them thinking:
“Oh, how I applied the dependency injection design pattern to elegantly decouple my classes and make my codebase easier to maintain in future.” (self-high-five)
Nope.
Even those who talk as if they love every second of it spend significant time on boring, monotonous or frustrating work. You can hear cursing in a programming office at least as much as in a car service. Honestly!
It’s perfectly fine if you sometimes hate programming.
Yes, “maybe it’s not for me?” is a common question when you’re overwhelmed and frustrated. It’s just normal. Yet, programming is for you. If you’re reading this, this means you care. If you care, you will make it.
Myth #2: There is so much I don’t know. I’m never gonna learn all this!
This is another highly common thought (maybe more important than Myth #1). I’ve heard many of my readers complain about it. And I can absolutely see the reasoning behind it.
We’re in a field so broad that the deeper you dig in, the more you realize you don’t know.
Even thinking about this made me feel bad. Man, it’s that easy to get overwhelmed.
The good part: You don’t have to know everything. You need to know just enough to be aware of how to find out what you don’t know.
For now, be sure you are aware of the high-level basics of whatever you’re working with.
Let’s back this up with an example.
If you’re experimenting with CSS, you should know it is for applying styles to HTML elements. You can make a button have border, color, shadow or animation. You can’t say what should happen when you click the button (you need JavaScript for this).
So if you need to animate an image when a button is clicked:
- First, you must have the image and the button elements (HTML)
- Then you can set animation for a specific class (CSS)
- And you can add the class to the image when the button is clicked (JavaScript)
Say you read this in a tutorial once. A week later, you must add a shadow to an image when a form is submitted. You know what to look for. You have an overall understanding of HTML, CSS, and JavaScript and which part they are responsible for in this functionality.
The rest is Googling the right words. In this case, “css add shadow” and “javascript callback form submit”.
See what we did there?
Learning programming the “right” way
As you see and probably know from your own experience, learning programming takes time — sometimes years. Despite what some “learn programming in 2 weeks” courses say!
When starting out, it’s important to build the right habits to learn efficiently. Most of the early days you spend on tutorials, guidelines, documentation or often all three at the same time. This is what we all do.
Some make the most out of their learning hours. Meanwhile others feel like they make progress but actually only copy and paste commands and follow instructions.
There is a habit for maximizing learning hours and it’s called “Learning Slowly”.
It’s a slightly different way of approaching tutorials which:
- Makes programming more fun (as boredom is a common problem)
- Makes you less dependant on tutorials
- Uses gamification
You can try it out with this 4-minute exercise at the end of the article. Let me know how it goes!
This post was originally published on MyFirstITJob.
What’s next?
Not giving up and learning efficiently is great — but sometimes not enough to get you a programming job.
Next, I’ll focus on what employers look for in a junior developer and how to stand out from the crowd for any job position.
