Summary: So you want to be a professional coder?

Update: I wrote a more detailed version of this article with a bit of explaining here.

My opinionated list of things you should and shouldn’t be doing; in no particular order:

1. Learn to touch-type with all 10 fingers. Never look at your keyboard ever again. Learn to do at least 60 WPM
2. Never use a line of code that you do not fully understand
3. Do not use too many if/switch statements, try to use simple object lookup when you can
4. Get comfortable reading API documentation, understand all the syntax coders use to communicate things like types, required/optional, order of things, aliases, dependencies, etc.
5. Get comfortable reading and debugging foreign code that you’re seeing for the first time. Use interactive debugging (breakpoints, step, …) when you can but do not underestimate the value of print debugging
6. Don’t guess when debugging, learn how to isolate the issue, perform sanity checks, and only after that, formulate a theory about what might be wrong
7. Get comfortable Googling for things. If you’re coding and your browser does not frequently hit google.com, you’re probably doing it wrong
8. Understand the difference between: a function call and a function reference, pass by value and pass by reference and whatever weird thing JavaScript does
9. Understand everything about all the possible data structures, what are they good at and what are they bad at. Learn how to implement and work with those data structures in your language
10. Learn about the imperative vs declarative ways of programming. Try to convert code written in one way into the other.
11. Learn a terminal editor (you don’t have many options here, it’s either Vim or Emacs), even if you’re not going to use them daily. You want a good editor when your only option is to ssh somewhere to make changes. Also, learn tmux or screen
12. Learn about tab-completion and use it in all possible ways. Tab should be the most used key on your keyboard
13. Lint your code on file save. Also make your editor get rid of whitespace errors
14. Be consistent with your indentation. Never mix tabs and spaces
15. Make your editor show the vertical 80-characters-line and do not cross it.
16. Always use version control, commit early, commit often. Use descriptive commit messages that answers the question: why this change
17. Think long before you type, read more than you write. There is a reason vim starts in ‘reading’ mode
18. Learn how to write tests first. When you have guiding tests before you have code, you are no longer guessing solutions, you have a way to immediately verify them
19. Don’t waste time writing tests for every freaking thing. Learn when tests provide value and invest your time there
20. Unless you can measure quality, don’t bother measuring how much of your code is tested. The quality of the tests is what matters. Focus on that instead
21. Change your attitude toward bugs and problems, it’s always great to face them because you’ll probably learn something new, and it is easy to make progress right then and there. Don’t just solve the problem, understand why it happened. The stack trace is your best friend
22. Do not overwork or stay late. Sleep when you need to. Sleep often if you can. Take plenty of breaks to move your brain back into the creative diffuse mode
23. Split a big feature into small increments with testable outcomes, focus on one increment at a time
24. Invest a bit of time coming up with descriptive names everywhere, files, variables, functions, classes, tests. Writing software is mainly about communicating implementations
25. Follow the 10-max rule everywhere. No more than 10 lines per function, 10 functions per file, 10 files per folder, etc.
26. Use named arguments in functions and don’t rely on arguments positions
27. Ditch your mouse where possible, you can do everything with your keyboard (even browsing and things like Gmail)
28. Learn the standard library in your language. Don’t memorize how to use it, just be aware of the existence of a feature here and there
29. Use comments as a last resort only when you can’t communicate them in code itself
30. Get comfortable with Regular Expressions but don’t use them in production code until you’re super comfortable with them
31. Never trust input from a user. Validation and sanitization are not optional
32. Solve one problem in multiple ways and then pick one solution
33. Don’t multi-task. Turn off all notifications and minimize all distractions before a coding session
34. Don’t be too attached to a language or a framework. The best things are always not invented yet. However, stop “learning” new languages, and instead “use” them to build things
35. Handle exceptions when you can but also know that some exceptions should just bubble up
36. Stop trying to time-estimate things because you simply can’t
37. Learn Bash, Cron, and the Linux way of automating things
38. Shorten the feedback loop in your development process (watch this)
39. Teach an absolute beginner how to code
40. Read books (split 50/50 between technical and non-technical), put a goal of reading a book per week/month or whatever you’re comfortable with
41. Practice logical thinking and analysis, play puzzle and strategy games
42. Learn how to measure before and after you implement a change, understand and use the OODA loop

IF you agree with everything in this list then something is wrong with you. Get some opinions, all professional coders have them.

Thanks to Koen van Gilst for reviewing this!

Samer Buna is an author for jsComplete, Pluralsight, and others. His most recent courses are Learning ReactJS and Building Scalable APIs with GraphQL.