This article may contain affiliate links which may earn the author a commission if products are purchased through the links.

There are many intricate details that you could never foresee going into programming. Statements such as “I want to learn to program in React.js” omit an entire plethora of other technologies you will have to learn as well. For example, Learning React.js most likely means learning Node, JavaScript, probably Redux, and definitely hundreds of other things such as NPM, GIT, Mongo, Yarn, and how to use your browser’s development console.

Malcolm Gladwell’s 10,000 hour rule suggests that 10,000 hours of “deliberate practice” are needed to become world-class in any field. As I’ve only become a developer fairly recently, I can accurately tell you how long it will take – forever. I have spent approximately 3,000 hours studying anything and everything to do with becoming a web developer, and I am no where near half way to learning what I want to know.

Have no fear though. In addition to pushing me to the edge of a panic attack, it has also been a fulfilling and enlightening journey. I will skip ahead to the enlightenment part – you are allowed to cheat in programming. You can easily look up the Microsoft Vision API reference, Google the difference between debounce and throttle, and save room in your head for your favorite ramen recipes.

As what I hope to be helpful advice for you, and a reminder to myself, I have written some tips which may shave a couple of hundred hours of learning off of your adventure. Some do not have to do specifically with programming, but these are probably the best pieces of advice.

1. Use the agile development method – plan, sprint, release, repeat. Trying to make a super-awesome, next-level, game-changer of an app will quickly turn you into worm food. Instead, the agile development method urges you to produce working code in stages (or sprints). This may sound harsh, but producing an app in 4 weeks which is 75% of what you’re looking for is better than producing an app which is 99.99% of what you’re looking for in never-going-to-happen. Even though I’m usually a team of 1, I still try to use scrum methodology – or at least a kanban board. You don’t need expensive software – the “sticky notes” program that came with your computer can help you stay focused.

2. Don’t give up. You may already be almost to your destination. If you’re using the agile development method, your app is probably already growing more awesome every week.

3. Never trust the client. I don’t mean your clients which are paying for your new 4K monitor, but your application clients. You never know what garbage you will receive from the client. Build applications heavy on the API side and light on the client side. This will allow you to develop with security, modularity , and simplicity at the same time.

4. Do not assign variables, set them using a function. Instead of using carColor = “blue”, use car.modifyColor(“blue”) which will allow you better decoupling and a central place for logic and error checking.

5. Use Test-Driven Development (TDD). Instead of performing multiple steps to get to the part of the program you’re working on and testing that A, B, and C are working, test the modular functions and abstractions which your program should be comprised of. You can’t work on a large project without introducing regressions; you need regression testing.

6. “The longest path between two points is a shortcut.” Saving a second by naming a variable l instead of lengthOfLongestSide could cost you many hours of troubleshooting later.

7. Handle every error. Before small errors become large festering pustules, put an end to them.

8. Simpler is better. If you find yourself writing code and thinking, “Gee, whiz! This is clever!”, the you of tomorrow which has learned to stop saying “Gee, whiz!” will instead be saying “WTF was I thinking?” Re-factor code to be simpler. If you must do something clever, comment it so you can explain what you’ve done. You’ll thank the you of the past.

9. Pass objects instead of properties. Pass a car object instead of car.exteriorColor when appropriate in case you later discover the receiver needs additional properties.

10. Your function should do one thing. getSalary() should not be a misnomer for checkIfUserIsAdminAndGetSalary(). Is your function a pure function or does it introduce side effects?

11. Make your apps more portable. Keep application settings out of the code.

12. Fake it until you make it. Your program connects to an API from the NASA space exploration center and you don’t have access? Make your own nasaApi() function which returns the fake data you need until you get the data you want.

13. Sometimes “not false” is better than “is true”. Sometimes silly things, like a value of -1 equating to True, can be a real head-scratcher. Performing different tests may save your sanity.

14. Program like there is no console.log(). As you start developing, it will be easy as pie to just print values to a console. Then, you will discover what a pain it is deciphering stuff in the console, getting erroneous error messages, and enabling and disabling console messages.

15. Avoid anonymous functions. When your program crashes, it’s nice when you know where it’s crashing.

16. Build periodically. You will not be happy if your program doesn’t build after successful development.

17. Don’t teach yourself. Yes, you should tinker, modify, and even copy, but when you teach yourself without proper guidance, you learn the incorrect way to do things as well as the correct way. Look at the code of people (and preferably the peer-reviewed code of people) whom have already solved what you are trying to learn. There are thousands of open-source projects on GitHub which you can learn from. If you are making frequent mistakes, make certain that you are understanding and will remember the correct way before moving on.

18. Abstract! The easiest way to begin is by drafting logical blocks that do what you want in plain English. For example, “pass the form data to the API” then “API returns address or an error in an unknown time”. Then, when it’s time to write your code, it will practically write itself. UML sequence diagrams are great for plotting logic flow.

Becoming a programmer is an enjoyable journey and rewarding hobby and career that you will never regret taking! Good luck!

For additional reading, you may wat to check out Code Complete by Steve McConnell, Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin, and Head First Learn to Code: A Learner’s Guide to Coding and Computational Thinking by Eric Freeman

avatar

Carl Mann

Full-Stack Developer

Former owner of an I.T. consultancy business in Southampton, NY, Carl gave up the hustle-bustle of I.T. to live his dream of becoming a full-time application developer. When not busy blogging or programming, you might find Carl out taking a ride on his motorcycle or hiking off in some woodland trails.

Leave a Reply

Your email address will not be published. Required fields are marked *