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.
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.
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.
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?
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.
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.
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.
Logging is not testing. Compiling is not testing. Showing “it works” is not testing.
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.
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.
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.
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.
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.
Code is not sacred. Don't get too attached to code you wrote and avoid religious wars around the "right" way of doing something.
Thank you kind strangers for sharing your experiences elsewhere. Tips 11 and 12 are from https://reddit.com/u/sonstone.
not affiliate links