Pro Programmer
Professional Tips

Professional Programming Tips

Use your keyboard efficiently

Touch-type

You need to learn to touch-type with all 10 fingers (if you have them) and never look at your keyboard ever again. However, do not get obsessed with your typing speed. If you can do 60 words/minute, that is good enough. You do not need to be faster than that. Just make sure that you do the 60 WPM without looking at your keyboard.

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 touch-typed with 4–6 fingers on Qwerty and was actually doing over 90 WPM, but I did not like the fact that I was not using all of my ten 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 ten fingers is possibly the best decision I have ever made as a coder.

Ditch the Mouse

Try to ditch your mouse where possible. You really can do everything with your keyboard (even browsing and using applications like Gmail). This is especially true if you touch-type with all ten fingers, because every time you use the mouse you are 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.

Use Tab-completion

This is probably the most important tip about using your keyboard. You HAVE to remember to use tab-completion in all possible ways.

The Tab key should be the most used key on your keyboard!

Tab-completion is not only about the speed of typing, but more importantly, it helps you avoid mistakes and be aware of what you can do.

Modern programs actually come with tab completion out of the box (for example, test it in Node’s REPL mode). Other programs , like Git for example,  require adding a script to enable tab-completion and it is totally worth it.

Use your editor efficiently

Pick a Terminal Editor

You need to learn how to use at least one terminal editor. Do not make excuses to skip this. A terminal editor is not “old-school” or not needed today.

When it comes to picking a terminal editor, you do not have many options. It is either Vim or Emacs.

Even if you are not going to use a terminal editor on a daily basis, you still need to be comfortable with a good one when your only option is to ssh somewhere to make changes.

Pick a Terminal Multiplexer

You need to learn how to use a terminal multiplexer like tmux or screen. I personally prefer tmux.

Always run your terminal commands in a tmux/screen session. This includes the command to run your terminal editor too.

Why? Because you can quit the terminal and re-launch 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.

This is very valuable when you work on remote servers because your session will stop being dependent on your network connection. You can re-attach your terminal to a tmux/screen session any time. You can also invite other users to join your same tmux/screen session, which is super helpful for remote pair programming and peer reviews.

Use Linting and Formatting Tools

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. Have another keyboard shortcut to auto-format the code. In JavaScript files, I use ESLint with Prettier. Prettier can be integrated with ESLint, so I have a single keyboard shortcut that fixes my obvious lint problems and formats the code in a much better way that I would manually do.

If you insist on not using an auto-format tool or if no good tool is available for your language of choice, then you have to at least be consistent with your indentation.

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

Make your editor automatically fix whitespace errors and insert a blank line at EOF. Always check your Git diffs before you commit them and make that a Git pre-commit hook if you can.

If you code in JavaScript, do yourself a favor and just use Prettier with ESLint.

Use Snippets Only if You Write Them

I manage my own snippets. I only add a snippet when I see a need for it. This proved to be useful as I used to import popular snippets, use them for a while, and then forget that I had them.

Snippets are handy for big template code that you use often. For example, if you use React, you should have a React class component snippet and a snapshot testing snippet. Do not use snippets for small code.

Alternatively, use a tool to generate files in your project based on these big templates. I use a command that generates both a React component file and its snapshot testing file. This also helps me not forget to add a test file.

Spell Check with Your Editor

Good editors will automatically spell-check what you write in certain file types, like when you author a Git commit message. However, before committing a new code file, I always force the editor to spell-check everything anyway. A quick visual scan can point out some valid mistakes, especially when you are creating content with mixed English, like HTML.

Know Your Programming Language

Read Code

Get comfortable reading documentation. 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 are about to do.

Be Familiar With What Your Language Can Do

Learn the standard library of your language. Do not 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 Paradigms of Your Language

Learn about the imperative vs. declarative styles of programming. Try to convert code written in one way into the other.

Learn the functional-programming capabilities of the language. Learn to always use Pure Functions. Learn about immutability and how to avoid shared-state. Learn about Composition.

Learn to Love Debugging

Understand That Errors Mean Progress

Change your attitude toward bugs and problems. It is always great to face them because you will probably learn something new and it is easy to make progress right then and there. Do not just solve the problems though. Understand why they happened first. The stack trace is your best friend.

Get comfortable reading and debugging foreign code that you are 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.

Resist the Temptation to Guess

Do not guess when debugging. Learn how to isolate the issue and perform sanity checks, and only after that, formulate a theory about what might be wrong. Your first instinct will always be to guess. Resist it.

Google First

Get comfortable Googling for things. If you are coding and your browser does not frequently hit google.com, you are 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).

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 cannot measure the effect of the change, it is 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. 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.

Never. Stop. Learning.

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

Do not 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 are good at and what they are 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 do not use them in production until you are very 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.

Implement side projects for yourself, your family, and your friends. Understand their problems and try to come up with solutions for them. Get feedback from your small group of users and understand the problems in your code based on that feedback. Improve and iterate. If you cannot find early users to build for, focus on reading more code. Pick easy projects and consume them from A to Z. Understand every line of code in the project and ask when you need further explanation.

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, do not waste time writing tests for every freaking thing. Do not test what is already well-tested. Learn where and when tests provide value and invest your time there, and unless you can measure quality, do not 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, focusing on one increment at a time. Define the outcome, then implement the increment. If you write more than ten lines of code without testing them somehow, you are probably doing it wrong.

Optimize Your Time

Do not multitask. We are not wired for that. Optimize the blocking things in your process that encourage you to multitask, like waiting on a build or a test run. If you cannot make them shorter, find a manager for them. Just like Node.js manages blocking IO in threads for you, find something to automate what blocks 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 reative diffuse mode.

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

Stop trying to time-estimate things because you simply cannot. When someone asks you to do a time-estimate, the only correct estimate is: When it is done.

Think and Validate

Think long before you type and 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 is not. It validates good solutions and improves your thinking skills.

Practice logical thinking and analysis and 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. Do not be generic about this and never “catch” all. Make sure you have a way to review and reflect on the exceptions that happen in your code in production.

Write Readable Code

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

Use named arguments in functions and do not 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 do not 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.

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, and 10 items per list.