5 Common Traps Junior Developers Fall Into (And How To Avoid Them)

Learn to focus on what matter.

In today’s extremely chaotic landscape, the world is filled to the brim with distractions and ineffective time sinks. Unfortunately, a lot of developers fall into these traps, especially junior ones including myself when I started out into the world of programming. In this blog, I will cover 5 traps that junior developers in particular often fall into, why they’re actually traps instead of opportunities, and how to get out of them.

Tutorial Hell

There are so many amazing tutorials nowadays, and that’s a huge net good for the community - The tutorial landscape has exponentially improved compared to 10 years ago, making the software world far more accessible. However, the problem with tutorials is that a lot of developers don’t realize that they’re merely a starting off point, not a path towards becoming a senior engineer or even a junior engineer capable of landing a full-time position.

Tutorials should only be used to build a basic understanding of whatever language/framework you are working with and that’s it. You shouldn’t be at this stage for more than 1 month, maybe 2 if you are completely new to programming. However, I see so many developers do tutorial after tutorial for months, trying to learn every possible component one can build within their primary stack (e.g. basic rendering -> onboarding -> animations -> video chat -> push notifications -> magical Christmasland). It’s even worse if you are doing tutorials for different languages and frameworks, because on top of being in tutorial hell, you also have no depth and only breadth, which is terrible for job searching.

You may feel like you’re making progress doing so many tutorials, because you are writing different code every time. Here’s why this is not the case:

Writing code is indeed a core way engineers learn, but the educational value you get from it is heavily dependent on how you do it. When you are doing tutorials, you aren’t building much real technical proficiency outside of the very basic surface level understanding. When you spend too much time on tutorials, you are merely refining your reading comprehension skills instead of actually becoming a better engineer.
Tutorials solve neat, cleanly packaged, predefined problems. This is not how software works in the real world. When you’re actually working, you will never get a problem that is 100% defined like a tutorial is, and you actually grow as an engineer by solving more and more ambiguous problems over time. If you constantly need a heavy guiding presence like a tutorial, you will have a hard-time shipping in a professional, production environment.
Tutorials are made to be accessible, so millions of people can easily do it, regardless of skill level. This means that by definition, your tutorial accomplishments, even if they are for monster 50+ hours tutorials, do not stand out. And in today’s ultra-competitive software landscape, especially among junior engineers, you need to either stand out or be unemployed.
Tutorials are always shallow, because their focus is on just getting stuff working. This is especially true for all the “popular app/website clone” tutorials. These tutorials only build the happy flow, and getting the initial happy flow working for a product is only 1% of the journey. The real journey is handling the edge cases, making the code resilient across a variety of screen sizes and operating systems, and gracefully evolving your product based on user feedback. Depth is absolutely crucial as a software engineer, so you need to get out of the kiddie pool.

To illustrate how to avoid this trap, here is how:

1.Start with tutorial where they have you build a sleek sample that lets you browse a list of famous landmarks and view a full page of each landmark’s details if you tap into one. Even though you are incredibly thorough with it play around with the code at each step). ~2 weeks

Immediately after the tutorial, start building a side project. After 2.5 months, tons of Googling, and tens of thousands of lines of code, you will now have a pretty polished and complete project. The code might be messy but the if it is fully featured then consider yourself a fairly capable (but far from good 😂) developer now.

As you can see, we literally only spent 2 weeks in the tutorial phase, and this would have been 2 days if we worked on this full-time instead of as a side project. You should do the same: Get out of this tutorial state within the aforementioned 1–2 months and just start building, either through side projects or open source contributions. You’ll have way more fun, achieve way more impact, and grow a lot faster.

Certification Collection

Certifications are effectively tutorials++ in that that they’re still very structured and predictable. The difference is that instead of giving neatly defined scenario -> answer, you only get the neatly defined scenario and have to come up with the answer yourself on some test you need to pass. As a reward for having to come up with the answers yourself, you get a nice certificate at the end, which you can then share on social media and get 100 likes.

I firmly believe that you shouldn’t get any certification unless it’s a hard requirement for a job you really care about. I think why a lot of people value certifications is because they are used to the school way of thinking, where you wanted to grind out as many certificates and awards as possible to get into a good college. Succeeding at school takes a lot of effort and is definitely hard, but in the end, it’s fairly straightforward and follows a very defined set of rules (I will save my rant on how schools don’t encourage enough critical thinking for another time). Software development, especially among the top companies, is literally the complete opposite of this. At any meaningful tech company, software is a giant ball of chaos that you’re adapting to on the fly while hoping your product doesn’t catch on fire. Good software engineers have to be nimble, versatile, and flexible, and pursuing certifications like they’re the Infinity Stones builds a mentality and working style that is the complete opposite of this. True learning comes when you’re free-styling and forced to go off the beaten path.

Let’s say you want to prove to employers that you’re good at Android. Instead of getting an Android certification, try building an Android side project app that gets a lot of users instead. This is far more indicative of your actual potential within a corporate tech environment.

Competitive Programming

From my understanding, competitive programming came crashing in during the data structures and algorithms (DSA) wave ~15 years ago when every tech company ever started jamming their interviews full of DSA problems. However, in the current climate, I feel like companies are realizing that DSA doesn’t give a complete, holistic evaluation of an engineer’s skills, so they’re not as extremely bullish on it anymore.

Don’t get me wrong, knowing DSA is still important, especially for passing interviews. However, I feel like doing competitive programming to help with your job search is like bringing a rocket launcher to a knife fight. You can easily ace the DSA rounds for any company, even Big Tech, with just Leetcode. Something important to remember about DSA is that it’s not meant to be an accurate predictor of how you’ll do on the job - It’s just the best companies can do given the constraints of an interview (i.e. in the span of a few hours, gauge how effective an engineer would be working across years at their company). DSA problems are hard, but again, they are straightforward - You take some input A of type B and return output C of type D. Software is not as clear cut as that, which means that it doesn’t really make sense to hyper-index on DSA - Just learn enough to pass the interview and that’s it.

Actually being impressively ranked at competitive programming is incredibly difficult, and for the time it takes, the returns really aren’t great helping you find a job and definitely not for leveling you up once you have a job. I also don’t think I have ever seen competitive programming give a candidate a hiring edge. If you genuinely love the spirit of competition and solving these kinds of problems, by all mean, go nuts with competitive programming. But if you aren’t and just want to land a decent tech job, there are many much more effective ways to spend your time.

Building In Secret

As I’ve mentioned before, I pride myself on being honest when sharing advice, so here’s another cold, hard truth: Your idea almost certainly isn’t worth stealing. The execution is what’s valuable, not the raw idea. The idea is just the beginning, and there are very, very, very few ideas that are so groundbreaking that they are, in and of themselves, valuable. You can see this from how so many existing tech products nowadays are just better versions of older products - The tech game is almost entirely about the quality of execution.

There is also a very real cost when you keep your ideas and code completely secret to yourself: You lose the massive power of community. When you get an idea, share it with others to get feedback. This will help you understand if your idea even makes sense and if it is solving a real problem that others have or are at least aware of. You can also get a sense of whether the scope of your solution is a good fit - Maybe you don’t need to build as much as you thought to have a real product. On top of this feedback, building alongside a community also helps tremendously with motivation, whether you’re just sharing progress with them or actually working with teammates. When you’re by yourself, it’s much easier to get burnt out or distracted, abandoning the project and leaving it stranded.

So the next time you’re building a project, build in public. Share your idea to get feedback and open-source the code (remember to .gitignore those credentials and tokens though!). Ask people if they would evolve the product the same as you would. Most of the apps are open-source pretty much, even those with 100k+ installs. It proves to users that my code can be trusted, and it helps both the overall Android community and myself. The ultimate goal as a software engineer is to build delightful products that help as many as people as possible. If someone forks the 100k installs app and turns it into a 1 million installs app, we have accomplished my goal even more (albeit indirectly) and you can reflect this on your resume.

Trying To Choose The “Perfect” Tech

I have been asked some version of this question more times than I can count: “What technology should I use to build my project?”. A lot of engineers seem to believe that there’s some optimal technology for every scenario, and one of the perks of becoming more senior is that you get better at identifying that 1 perfect technology. This is not how software works.

In this modern day and age, there are dozens, if not hundreds, of ways to build a legitimately good solution to any technical problem. There is never any 1 technology that’s better than all the rest; if this were the case, software would be way too easy and developers wouldn’t be paid such cushy salaries. What usually happens is that there’s multiple options that are all good but for different reasons.

So what should you do if you can’t figure out what tech to use? Simple, just pick whatever you’re the most comfortable with. Do you have a lot of friends who are good with React? Then build your website in React. You want to build a back-end and you have some JavaScript experience? Then build it with Node.js. You still have absolutely 0 opinion? Just pick anything, as long as it’s relevant (i.e. you see job postings and LinkedIn activity talking about it). As mentioned before, time is the only resource that matters, so don’t get stuck in decision paralysis for weeks or maybe even months. Choose something within a few days tops and start building.