3.5 Mistakes Career Changers Make When Learning to Code (And How to Avoid Them)
When you went to school, you were rewarded for completing assignments on time and memorizing facts.
This same approach will NOT work for becoming an employable software engineer.
In fact, it will have the opposite effect.
On your learning-to-code journey, there are many mistakes you will make:
You’re going to mess up, produce sh*tty code and fail a ton of interviews.
These are unavoidable and necessary to your growth as a developer.
Some pitfalls, however, should absolutely be avoided. I’ve spoken with literally hundreds of you out there and learned what’s holding you back. Here are the 3 (and a half) biggest mistakes career changers make when they’re learning to code:
Oops, you became a glorified typist
A few months ago I was working with a young woman who completed a coding bootcamp which shall remain un-named.
She created a beautiful web application.
I was honestly impressed.
When I asked how it worked though… oof.
She needed help fixing a bug in this application for her portfolio. I asked a simple question about some code she had written and it became immediately clear she had no clue what I was talking about.
How was this possible?
I was genuinely curious so I asked her.
“I followed along with the instructions so I don’t know why it’s not working. It’s supposed to show a list of movies but it’s just blank.”
It’s a tale as old as time… or at least as old as coding bootcamps.
She fell into the tutorial trap.
Basically, you code what the person on the screen is coding without extending or re-writing any of the code.
The payoff: a shiny new app.
The cost: a false sense of mastery.
I know it’s tempting to get something pretty to look at. Avoid this temptation by breaking, extending and re-writing the code from any tutorial. You don’t need to understand every piece of code you’re looking at but you should be able to explain what is happening at a high level.
If the code you write is black magic to you then what happens when it breaks or needs to be changed?
Remember, there is no gold star for finishing a tutorial and no one is going to hire you based on a portfolio project you can’t explain.
Quantity over… everything
If you join my coding program, you’re going to build 2–3 complex applications and a few smaller projects that no one will want to see but will help you learn some fundamental concepts.
I can feel the disappointment when I explain this to people who are interested in joining Parsity.
You see, they think building 100 small apps is the path to getting hired.
They are obsessed with a portfolio… that no one will look at.
Imagine trying to stand out in a sea of recent grads who all made a weather-app, movie finder, meme-generator, TODO list and snake game.
Plot twist: you won’t.
When I was an engineering manager, the HR department would hand me a stack of resumes when we posted an open position. Do you think I’m asking the highly compensated software engineers on the team to look through every random link in this stack?
If the app you’re linking to has a sign-in page, there is a 100% chance I’m not going through the trouble of checking it out.
The reason why you want to focus on building 1 or 2 complex apps is 2-fold:
- You can go beyond surface-level knowledge in a few areas and fall down some rabbit holes while you learn how to test, deploy and secure your app. You simply won’t encounter interesting problems by launching a TODO app as a GitHub page.
- You now have an answer for the most common interview question: “Tell me about an interesting project you worked on and a problem you encountered.”
The Swiss-Army-Knife approach
I met a guy who was learning to code a few years ago.
When we bumped into each other at the train station recently, I asked how it was going.
“The market is brutal man. I’m switching into Python and taking some cyber security courses. I think I’m going to get an AWS cert and try to get into DevOps. I’m also still working on this full stack Javascript project with FreeCodeCamp. Hopefully something cracks!”
Me — 😦.
I wanted to grab him and shake some sense into him.
“Just stick to JS or Python! Build a full stack app and deploy it then get a pro to fix your resume and LinkedIn! Stop this madness I beg of you.”
Instead I just nodded my head and said, “Oh, cool.”
Shame on me.
I get it though. When you’re reading through job openings for software developer positions they have a laundry list of tools and technologies they want you to know.
There’s a bit of an unspoken expectation that if you meet ~50% of the requirements then you’re qualified. If you meet 100% then you’re over-qualified.
Most professional developers with a few years of experience have used 1–3 languages and will be strong in 1.
When you list half a dozen languages on your resume with barely any professional experience and another dozen certifications that are largely irrelevant for any software engineering position, it actually increases suspicion.
As my kids would say — “It’s sus…”
Instead, learn 1 general purpose programming language (Python or JS) and another 5–6 technologies which are relevant. Most dev shops will use Git, GitHub, MongoDB or SQL, Node/Express, Python, ReactJS and AWS. You can find the most common technologies in your region and reverse engineer your path from there.
The silent killer
The single mistake that kills most wannabe developers’ dreams is simple. It’s at the core of most of these other mistakes:
Inconsistency.
Their coding progress rises and falls with their motivation. You need a system.
Here’s the routine I used to learn to code and switch careers when I had 2 kids, 2 jobs and an hour long commute.
- Code every morning and most lunch breaks at work. Wake up 30 minutes earlier than usual to create time.
- Spend Saturday and Sunday mornings working on side projects
- Each night, write in my notebook what I’m doing the next morning to avoid analysis paralysis.
Habits have a compounding effect. Good habits beget good habits. You can guess what I’m going to say about bad habits.
I truly hope you avoid these massive potholes on the road to software engineer — I don’t want to see you 3 years later at the train station telling me about how you’re studying to become a prompt engineer.
Good luck!
