So you want to be a professional coder?

I have been coding for longer than I care to admit. I am mostly “self-taught”, but I did eventually take some programming courses in college which I don’t think contributed much to my overall coding knowledge and experience. You can only learn coding by building actual non-example things. In this article, I share my highly opinionated collection of tips, advice, and things I believe you should and shouldn’t be doing. Opinionated is the keyword here, a lot of professional coders out there disagree with some of the points I am going to make here.

I mostly code in JavaScript these days so some of the points here might be a bit biased for the language. Take it all with a grain of salt.

1 - Use your keyboard efficiently

Learn to touch-type with all 10 fingers and never look at your keyboard ever again. Learn to do at least 60 WPM and don’t obsess about going faster.

I actually learned touch typing out of necessity. I had to type on a keyboard with no labels and I was too poor to buy another one. For the longest time, I touched typed with 4–6 fingers on Qwerty and was actually doing over 90 WPM but I didn’t like the fact that I am not using all 10 fingers. A friend suggested that I should try Dvorak, and I did. Switching to Dvorak was not easy but forcing myself to re-learn typing with all 10 fingers is possibly the best decision I’ve ever made as a coder.

Learn about tab-completion and use it in all possible ways. Tab should be the most used key on your keyboard. Tab-completion is not only about speed of typing, but more importantly to avoid mistakes and be aware of what you can do. Modern programs actually come with tab completion out of the box (test it in Node’s REPL mode for example!). Some programs — like git, for example — require adding a script to enable tab-completion and it’s totally worth it.

Try to ditch your mouse where possible. You really can do everything with your keyboard (even browsing and applications like Gmail). This is especially true if you touch-type with all 10 fingers, because every time you use the mouse you’re moving away from the home row and you need to re-establish your position when you come back. I use the mouse mostly when I am not actively typing.

2 - Use your editor efficiently

Learn a terminal editor and do not make excuses not to. You don’t have many options here, it’s either Vim or Emacs. Even if you’re not going to use a terminal editor daily, you need to be comfortable with a good one when your only option is to ssh somewhere to make changes. Related; learn tmux or screen and always run your terminal editor in a tmux/screen session. You can quit the terminal and relaunch it to exactly the same point you left it, with all the same history, open buffers, and the exact state of the commands you executed.

Make your editor do the busy work for you. Make it lint your code on file save and have a keyboard shortcut to automatically fix obvious lint problems. Use code snippets and auto-complete (yes, terminal editors can do that too). Make your editor automatically fix whitespace errors and insert a blank line at EOF (always --check your git diffs before you commit them, make that a git pre-commit hook if you can). Also use your editor to spell check.

Be consistent with your indentation. Linting can help you with that. If you don’t have a strong opinion about this, avoid using the tab character and use 2 (or 4) spaces instead. A space is always one column while a tab uses different number of columns on different environments, and that presents a problem when the code is moved between environments. However, regardless of your tab/spaces choice, just be consistent about it and please, please, never mix tabs and spaces. Show whitespace characters in your editor and always fix any pasted code to match your indentation style.

3 - Know what your programming language can and can’t do

Get comfortable reading API documentation and learn the standard library of your language. Don’t memorize how to use things, just be aware of the existence of powerful features in your language, and know how to quickly look them up.

Understand the syntax used in documentation to communicate things like types, required/optional, order of things, aliases, dependencies, etc. Understand and use the man command to know your options and even to just verify what you’re about to do.

Learn about the imperative vs declarative styles of programming. Try to convert code written in one way into the other. If you use JavaScript, learn the functional-programming capabilities of the language (here’s a good book about that).

Understand the difference between: a function call and a function reference, pass by value and pass by reference, and whatever weird thing JavaScript does.

4: Learn to love debugging

Just like young children, code communicates by misbehaving. 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 though, understand why it happened. The stack trace is your best friend.

Get comfortable reading and debugging foreign code that you’re seeing for the first time. Use interactive debugging when you can (breakpoints, step,…) but do not underestimate the value of print debugging. In some cases, print debugging is far more effective than interactive debugging.

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. You’re first instinct will always be to guess, resist it.

Get comfortable Googling for things. If you’re coding and your browser does not frequently hit google.com, you’re probably doing it wrong. Searching is not only about fixing problems, I use the search more often to get inspired about what I am planning to do next. You can copy things from the web and use them in your code as long as you understand them. Never use a line of code that you do not fully understand (just because someone on the web told you it will work, or even because it worked for you before).

5: Measure and be organized

Learn how to measure before and after you implement a change. This is more important when your change is an optimization. In that case, if you can’t measure the effect of the change, it’s probably not worth doing.

Understand and use the OODA loop: Observe, Orient, Decide, and Act. When you apply it to coding wonderful things happen. Most importantly, never decide or act before observing and orienting.

Shorten the feedback loop in your development process as much as possible (watch this). Automate development commands that you run often and test your changes as close as possible to the “preview” area.

Always use version control and commit early and commit often. Use descriptive commit messages that answers the question: why this change. Version control is not only for big projects and teams. I use it for tiny projects that I do all by myself. The benefits are too good to miss.

6: Never. Stop. Learning.

When you stop learning in the coding profession, you are basically decaying into irrelevancy faster than you can imagine. Put a goal to read a book and take an online course every month or so, or even every week if you can.

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.

Understand everything you can about all the possible data structures (Set, Stack, Queue, Map, List, Tree, Heap, Graph, ...) and their variations. Learn what they’re good at and what they’re bad at (at least in terms of CRUD operation). Learn how to implement and work with those data structures in your language. This is a lot more important than memorizing algorithms.

Learn Bash, Cron, and the Linux way of automating things. Learn Regular Expressions, although maybe don’t use them in production until you are super comfortable with them.

Challenge yourself. Try to re-learn what you failed to understand previously. For the longest time, I could not learn Vim and I hated it, but after a few years of struggling, it was the best thing I did not give up on. Good things are hard to learn.

One of my favorite ways to learn is to teach, try to teach an absolute beginner how to code.

7: Test First. Test Often.

Learn how to write automated 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.

However, don’t waste time writing tests for every freaking thing. Don’t test what’s already well-tested. Learn where and when tests provide value and invest your time there, and unless you can measure quality, don’t bother measuring how much of your code is tested. The quality of the tests is what matter. Focus on that instead.

Split a big feature into small increments with testable outcomes, focus on one increment at a time. Define the outcome, then implement the increment. If you write more than 10 lines of code without testing them somehow, you’re probably doing it wrong.

8: Optimize your time

Do not multi-task. We’re not wired for that. Optimize the blocking things in your process that encourage you to multi-task, like waiting on a build or a test run. If you can’t make them shorter, find a manager for them. Just like Node.js manages blocking IO in threads for you, find something to automate the blocking things in your development process and notify you only when you need to take action.

Turn off all notifications and minimize all distractions before starting a coding session, but do take plenty of breaks to move your brain back into the creative diffuse mode.

Never overwork or stay late, you’re much less productive when you’re tired, and you’ll most likely make expensive mistakes. Sleep when you need to. Sleep often if you can. Do not force your body to stay up on false energy. Do not fight mother nature about this.

Stop trying to time-estimate things because you simply can’t. When someone asks you to do a time estimate, the only correct estimate is: “When it’s done.”

9: Think and validate

Think long before you type, read more than you write. There is a reason Vim starts in ‘reading’ mode and has great navigational features. When you think you reached a conclusion to drive a change, research the code for potential problems before you implement that change. My most used git command is git grep.

Solve one problem in multiple ways and then pick one solution. You might think this is a waste of time but it’s not. It validates good solutions and improves your thinking skills.

Practice logical thinking and analysis, play puzzle and strategy games when you can. Your analytical skills are a lot more important than your syntax skills. Invest all the time you can to improve them.

When it comes to working with any type of external input, validation and sanitization are not optional. Never trust input from a user. Validate on many levels: front-end, services, and even databases. Understand and use database constraints.

Handle exceptions when you can but also know that some exceptions should just bubble up. Don’t be generic about this. Never “catch” all. Make sure you have a way to review and reflect on the exceptions that happen in your code in production.

10: Write readable code

Invest a bit of time coming up with descriptive names everywhere, files, variables, functions, classes, tests. Writing software is mainly about communicating implementations. Use comments if needed but only when you can’t communicate what you want to put in a comment with code itself.

Use named arguments in functions and don’t rely on arguments’ positions. Do not use too many if/switch statements and try to use simple object lookup when you can. IF you have to use if/switch statements, avoid nesting them.

Make your editor show the vertical 80-characters-line and don’t cross it. This is not an old school practice just because your monitor got bigger. Long lines make everything harder to read. There is a reason a Medium article on a big screen has an 80 characters maximum width.

Finally, try to follow the 10-max rule of thumb everywhere. No more than 10 lines per function, 10 functions per file, 10 files per folder, 10 items per list.

Thanks for reading.

I've expanded this article in my How to Become a Professional Programmer book: