The number one way to learn anything is to practice frequently. A friend of mine often says, “Let those fingers dance on the keyboard”. The best practice is to code daily for at least 30 minutes.
There is a saying, “If you don’t use it, you lose”. This is very true while learning to code. When you code daily you are building a solid and ever expanding bucket of knowledge. That knowledge is compounded in that each topic is built upon the previous topic. Drop by drop, the bucket fills up. When you code sporadically, your bucket of knowledge is drying or leaking out as fast as you are sporadically learning.
Intent means planning what you will be coding and what is the end result so you are not wasting time wondering what is next. That intent can be following a tutorial, doing a short coding problem (HackerRank), or a personal project (my 100th Todo list).
A second great intent is to read code. This is a great way to learn what high quality code looks like and will help build a solid coding foundation.
Take the time to try different forms of learning to determine which works best for you. There are many ways to learn how to code such as listening, reading, watching, doing, or a combination of the three. Some developers learn best in a structural environment like a school or boot camp. Other developers learn best by reading source code documentation, short blog posts, or technical books. Finally, there is a big group who love love love YouTube and can learn from listening and watching it. Find what works for you!!!
A great method of improvement is to refactor or rebuild something you have done in the past. An example is learning how to solve a coding technical problem.
- The first iteration works but isn’t pretty, doesn’t follow industry standards/conventions, or is optimized. It also took you all day, asking for lots of help, and lots of research to learn how to solve the overall issue.
- The second iteration of the same technical problem is focused on solving the problem without the hand holding. Did you learn the intended lessons or just copy and pasted?
- The third iteration of solving the same problem could focus on making the code pretty. This includes good variable naming and other industry standards.
- Finally, you could optimize the code or ask others how you can make your working code better.
This sequence of iteration allows you to cement what you learned in your mind and practice writing good clean efficient code.
I can’t stressed enough how important it is to work around other professionals in the same domain. When you are working on a shared project or building on the work of others it forces you to give your best or learn from others. This can influence you to write higher quality code or be exposed to high quality code.
A great method is pair programming. This is two or more developers coding on the same code base to achieve a goal. They are learning directly from each other while coding. The one caveat is you don’t need dead weight slowing you down. Working with others isn’t good if they are just talking trash instead of coding/teaching.
Code reviews are one of the best ways to improve yourself. A code review is when someone gives you suggestions on how to improve your code or if your code meets the desired expectation. This outside view is critical to spot issues that you may not realized and will help you become a better developer in the long run.
Linting is when your code follows a predetermined code styling guide. The goal is for your code to meet industry standards that makes it easier to be read and understood by other developers. I will admit I’m bad about this one. I paid the price in several interviews when specifically asked why something looked unformatted, hard to read, and easily fixed with a linter. The lesson learned was to use linters in your code editor. When it screams at you, make the fix (normally one easy click). Eventually you will make these corrections automatically and be coding like a pro.
This falls under managing your time and tasks so you are giving your best effort when coding. The process is to use a timer to create intervals of focused coding and short breaks. This helps to keep the mind fresh and not burnt out. The basics is to decide on the task, start the clock and work on that one task, and then when the timer stops take a short break. When coding with this technique, don’t multitask and avoid having conversations. Remember, you have a short time period to get one thing done well before your break.
Code Connector member Brett Rehberg wrote an excellent article about a potential path to mastering the Pomodoro technique at http://brehberg.info/pomodoro-technique/.