5 Things Every Beginner Programmer Should Know
- Get a Second Monitor
When coding, especially on bigger projects, you often require multiple tabs open on your browser, multiple code editors, and you will find yourself needing to switch around a lot. Having a bigger monitor, as well as a second monitor will really assist having a more comfortable and smooth coding experience. More screen real estate = more organized work flow = better code.
2. Get Comfortable With VS Code Shortcuts
When writing code, you often need to move lines of code a few lines up or down, or need to change all the occurrences of a variable name to a more accurate one. I used to waste lots of time meticulously working line by line, but finding out about VS Code shortcuts helped me see there were much more efficient ways to get things done. See this article for a few really good shortcuts.
3. Beware the burnout.
We all know that classic movie coding trope where the computer nerd character downs a bunch of red bulls, pulls an insane all nighter “hacking the mainframe” while random lines of green binary scroll over their face until they dramatically turn to the rest of their crew and say, “I’m in”.
Although its still one of my favorite film moments, the more mature part of me knows to not become too enchanted by such montages. It is simply not sustainable. Pulling all nighters, avoiding taking breaks, pushing yourself too hard, and not nourishing your body properly all contribute to burnout and keeping you stuck in work mode. The more challenging part of being in the “flow state” is that when sustained for too long, you are inviting exhaustion. We are still humans, not robots (for now), which means rest, relaxation, and knowing and respecting your own boundaries and work-life balance are going to be key to sticking to it for the long haul.
4. Learn to test as you go.
Early in my programming experience, I would try to write out my entire code before testing it. This would lead to many bugs in various places, and made determining where to begin the debugging a huge headache. However with time I learned about test-driven development (TDD), which refers to using tests built specifically for the code to make sure it works. While I am still learning how to write TDD tests myself, one of the lessons that I learned at Flatiron School was how to ensure your code is working correctly, by finding creative ways to test on your own. Whether using debugging tools such as Buybug and Pry, or console logs in Javascript, testing your code one section at a time can greatly increase your efficiency and save you enormous frustration. Of course we ultimately want to write “perfect” code — but be prepared that that will mean taking it one step at a time, with plenty of tests and debugging along the way.
5. Pair Programming
When coding there is an instinct to pull one’s code close and not allow anyone to see it until you have ironed out all the bugs. But I have found that one most helpful thing is to have another pair of eyes to help you out. Pair programming can refer to a few things. Sometimes its sharing a screen with your partner and working on the same page of code, having one person “drive” (write the code) and the other “navigating” (directing the driver, researching, coming up with ideas for the bigger scope of the code). It can also refer to working on a shared project but with each team member having ownership of different parts, with both programmers working separately but sharing and updating on their respective code base in the project. Or, lastly, it can be the simple process of sending your code to a friend to look over and debug.
I have been lucky to have had plenty of wonderful experiences with Pair Programming throughout my time as a software engineering student at the Flatiron School. In a recent project of mine, a bug that took an entire day to fix was immediately resolved after a fresh pair of eyes realized that the issue came down to a misspelled variable name. As frustrating as that was, it taught me an important lesson in having no problem in consulting with peers before spending 12 hours problem solving on my own.
