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.
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?
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.
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.
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
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
Top comments (4)
I think one portant aspect of any kind of development should be communication as well. Learning how to communicate effectively and when to communicate is very crucial. I have seen many people not communicating regarding red flags because of fear. By communicating early, many problems can be avoided.
Can you elaborate on this? I'm not entirely sure what you mean here. To me, the two are not mutually exclusive. You'll write programs that both use the stack (i.e. every time you make a function call) and in that very same program, you'll allocate memory on the heap (e.g.
malloc) ?Cheers,
Matt Chung
@memattchung
code should strive to be self documented. At least according to agile principle.
Clean code also tells you that your code should be self explanatory, that you could read code like one reads a text
I agree, that under ideal situations, code self documents. However, some of the best code bases I've seen are sprinkled with comments — lots of them. I like stating the
preandpost conditionsof my functions. Also, I like explaining the reasoning behind the module I'm building as well. Not only what it does, but what it doesn't do as well.Cheers,
Matt Chung
@memattchung