In my last 4+ years as a software developer, I've learned a few things about how to excel in this field. I've made my fair share of mistakes, and seen others make theirs as well. Today I'd like to share 4 mistakes to avoid as a junior developer. If you're a newer developer, I hope these pieces of advice will help you advance in your career and avoid some of the pitfalls I've seen.
1. Don't Call Yourself a Frontend Developer
I've seen so many software developers introduce themselves as a “frontend developer”, or a “React developer”, or something along those lines. Certainly there is nothing wrong with this if that is truly your job title. However, when you refer to yourself as a very specific type of developer, you limit your career growth. Why would you label yourself in a way that makes you sound like a one-trick-pony?
Perhaps you're content only ever being a frontend developer, and that's perfectly fine! But how do you know you will still only want to do that specific type of work years down the road? Even in the relatively short time I've worked in the industry, there have been times where I've gotten bored working on the frontend and find it invigorating to learn something new or touch a codebase I'm not familiar with. This wasn't the case when I started as an intern though. I was sure that I wanted to work on the frontend. Working with data all day is boring, right?! Nope! Now I love jumping back and forth and flexing my developer muscles in different areas. Afterall, this is what it means to be an engineer. We solve problems. If you hate problem solving and would prefer to do the same tasks over and over, software development is probably not for you.
I also think people label themselves this way because they are not yet confident in their problem solving abilities. They don't want to claim to be a fullstack engineer, and then be exposed as a fraud when they don't know how to solve a specific problem. This leads me to my second piece of advice:
2. It's Okay to Say, “I Don't Know”
Software Developers have done an excellent job creating a know-it-all culture. We boost our own pride by trying to always be the one with all the answers. This is evident by many peoples' terrible experience with sites like stackoverflow.
The truth is, you can't know everything. Computer Science is such a vast field of study, and in your career you will likely become more proficient in one small niche. This is why I've always felt it's ok to say “I don't know” when someone asks me something I genuinely don't know the answer to. This shouldn't reflect any incompetence, as long as you are continually learning as you advance in your career. Being able to find solutions to problems you don't know how to solve is a huge part of being a software developer. The more you find solutions to problems you previously had no clue how to solve, the more confident you will become in your ability to solve problems with an unknown solution in the future.
While saying, “I don't know” is an acceptable answer, saying “I don't know, but I'm happy to go figure that out!” is an even better one. A good developer knows how little they know, but is excited by the possibilty of learning something new. Remember that your attitude is everything. When you don't know the answer but respond with a positive, go-getter attitude, people will likely not judge you for your lack of knowledge, but be impressed at your willingness to find solutions.
3. Think for Yourself
In the world of software development, especially in frontend JavaScript land, the industry changes at a rapid pace. Technologies are always evolving and a new framework that's going to revolutionize the way we work seems to be released every week. There's always going to be a million different voices telling you what stack you should use, and the truth is not every tool is good.
This is why it's so important to think for yourself. Don't buy into the hype around some new technology just because other people are talking about it. Try it out for yourself and test it to develop your own opinions. In your job, you'll often have to decide between between different programming languages, frameworks, or packages, and it's important that you are able to explain to others why you prefer one over another. You certainly do not want to convince your team to use a shiny new technology, and then find out it's buggy or has little developer support. This is why, when writing production code, it's sometimes better to choose stability over newness. New does not necessarilly mean better.
As you think for yourself and develop your own opinions on things, remember to do so gracefully. Sometimes the difference between technology “A” and “B” simply comes down to developer preference. Two different tools can both work well and there may not be one correct solution. In this case you don't want to be pushy, but humbly explain why you might prefer one option over the other. At the end of the day, remember you need to be a team player, and if others don't agree with you, it might be best just to agree to something that everyone is happy with - even if it wouldn't have been your first option.
4. Know When to Ask Questions
As you are progressing as a software developer, you will inevitably run into a problem that you can't figure out how to solve. This is where you'll develop the skill of knowing when and how to ask questions.
Firstly, you do not want to be the person that runs to a coworker for help immediately when you encounter any problem. Try to exhaust your resources that are available to you before asking a coworker. This is also how you will develop your confidence to solve other problems. Always consult Google. There's a decent chance you are not the first person to encounter this problem, and the solution is documented somewhere online. Remember to read the documentation for whatever tool you're using! Asking if you're using a package or tool the correct way is usually a bad question because that should be explained in the tool's documentation.
You may find yourself looking through different Google search results and not finding any solution to your problem. When you run into a problem like this when using a third party package, try looking at the issues section of the project's repo. You might have run into a bug that has already been discovered and the project's maintainers are actively developing a fix. If this is the case, you might be able to temporarily rollback the dependency to a previous version before the bug was introduced in the meantime.
Sometimes, I'll even resort to asking my questions to ChatGPT to see if the AI overlords know how to solve my problems. They usually don't tell me anything I haven't already found from a Google search, but they might present the information in a way that makes me realize what I was doing wrong.
If you find yourself going down a long rabbit trail trying to find answers, there's certainly no shame in asking a coworker for help. I would try to find the solution on my own, but if I'm spending an hour plus trying to find a solution and am not getting anywhere, it certainly wouldn't hurt to reach out to a coworker who is perhaps more familiar with the codebase. A teammate may have run into this exact problem before, so instead of continuing to spend time solving it on your own, make sure it's not a solved problem. After a certain amount of time, the benefit of figuring it out on your own is outweighed by the time you could have saved by asking a coworker.
Finally, in cases where neither you nor your coworkers know how to solve a problem, I would reach out to an expert online. These are often the cases where I'll post a question to stackoverflow. I don't always get a good answer, but I am at least reaching a wider audience and might get a response from an expert in that particular area. To summarize, I would try to find solutions on my own by exhausting online resources, and then if I'm finding myself spending too much time on this, I would ask a coworker for help.