Valuable Tips for Junior Developers
Tags: programming, webdev, javascript, java
Published: 2021-06-05 21:36:21

Do not panic! You do not need to learn X language and know Y algorithm before you apply to Z tech company. The truth is, most senior developers would not pass a coding interview anyways. Here is what you should expect to learn at your first job.

## 1. Ignore the trivia

Many junior developers are overwhelmed with edge cases that they will never see. It is okay to fail. Most of the time, these problems only pop up in interviews, coding golf, or horror stories. Ignoring the click-bait will let you focus on what actually matters.

![trivial JS code](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/xgc01s2m6jydggdwek7s.png)
 
The best programmers are flexible and adapt to the current situation. When there is problem, they chat with their teammates or read resources like books, documentation, tutorials, forums, etc. It’s amazing how many problems can be solved by reading.

## 2. Don’t be a one-trick pony

A developer that fully understands the fundamentals is worth more than someone who focuses on language specifications. Again, ignore the trivia, and do not panic. Programming languages are tools for building ideas.

Ask yourself, who would you rather work with: The guy who always uses a hammer, or the guy that understands which tools and resources will let a project withstand time?

![Patrick with a hammer](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/wdb2cxzn23o6iribaeoo.png)

## 3. Pointers vs References

Pointers will not hurt you! There is nothing to be scared of. Believe it or not, many scripting languages like Python and JavaScript have pointers. They are just hard to notice because those languages do not specify a token for de-referencing pointers. Ever notice how object/dict properties behave differently than plain variables?

## 4. Don't forget about memory

The popular languages handle most memory management, but you are responsible for the rest. Are you a heap or stack programmer? What’s your favorite data structure? As your code ages and data grows, this choice becomes more relevant.

## 5. Patterns and Principles

My old mentor once said, “Anyone can write code, but very few can write architecture.”

Force yourself to learn programming principles like SRP, OCP, LSP, etc. This will keep your code clean and allow your programs to scale years into the future. When you are ready, learn to integrate those principles with design patterns. The hidden art keep programming enjoyable.

Remember, this is not something that is mastered over night. Start reading and practicing in small chunks now and it will pay dividends.

![The web of design patterns](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/tiitpuyubhtpluocj4xq.png)

## 6. Plan Plan Plan

Jumping into code is fun but it will come back to haunt you. Planning does not take as much effort as you think. Even a simple sketch on notebook paper can save weeks of patches.

Also, this is not limited to UI. Data flow and architecture can get complicated too. Writing down your ideas helps you think more clearly. Plus, it doubles as documentation.

## 7. Automate Tests

Logging is not testing. Compiling is not testing. Showing “it works” is not testing.

![Surprised Pikachu in terminal when tests pass](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/94usphdmgxtuu209ectg.png)

Write code to test your code because odds are you forgot basic functionality requirements. Writing tests first (TDD) is like planning ahead — it saves you from becoming an alcoholic.

If you cannot automate your test for whatever reason, make a text file with steps to manually test, and be sure to include expectations. This will ensure the same steps are followed every time and the whole team agrees on the what is considered a success or failure.

## 8. Documentation

Don’t wait until the project is finished to write documentation. Not only will you be ready to move on to new projects, but you won’t remember how most of the code works.

Just like testing and planning, documentation should be conducted throughout the life of the project. Documentation written before coding doubles as planning, but it should be reviewed afterwards.

## 9. Debugging

Mistakes happen so learn to use your debugger. It’s like learning to use a fire extinguisher. With experience, you will need it less but it is always there just in case.

Most debuggers let you pause execution, change variables, or skip large chunks of code. This lets you focus more on the bugs and less on running code.

## 10. Keep Learning

We all work in a rapidly changing field. Once you stop learning you become the human form of legacy code. Nobody likes legacy code.

You do not have to go back to school, but take some time out of your week to keep up with the coding world. Most importantly be open to new ideas. Remember, programming languages are tools, and new tools create bigger and better things.

## 11. Bonus: Code has consequences

Make sure you understand the "why" of everything you do. Why am I being asked to do this? How will it benefit the company? How does it impact customers? All that goes directly into each micro decision you make on each line of code you write.

## 12. Bonus: Work as a team
Code is not sacred. Don't get too attached to code you wrote and avoid religious wars around the "right" way of doing something.

## Other Articles
[What Boy Scouts and Programming Have in Common](https://dev.to/wadecodez/how-to-uphold-the-scouts-rule-to-programming-469j)

## Credits
Thank you kind strangers for sharing your experiences elsewhere. Tips 11 and 12 are from https://reddit.com/u/sonstone.

## Resources: Great Engineering Books

not affiliate links

[![Clean Architecture Craftsman Software Structure cover](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/b8mcfa4yv5exlgs5d2m8.png)](https://www.amazon.com/Clean-Architecture-Craftsmans-Software-Structure/dp/0134494164)

[![Growing Object Oriented Software Guided Tests cover](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/f88tzybon5g3vck8y3r6.png)](https://www.amazon.com/Growing-Object-Oriented-Software-Guided-Tests/dp/0321503627)
 

[![Design Patterns Elements Reusable Object Oriented cover](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/042r0gyr7zgrzvacgnf8.png)](https://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612/)


[![Head First Design Patterns Brain Friendly cover](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/pmpcj041l7ur0rafqqpf.png)](https://www.amazon.com/Head-First-Design-Patterns-Brain-Friendly/dp/0596007124)

[![Refactoring Improving Existing Addison Wesley Signature cover](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/jq423du4h50ki8vucd8j.png)](https://www.amazon.com/Refactoring-Improving-Existing-Addison-Wesley-Signature/dp/0134757599)