Five Things I Tell Every New Developer to Learn

In my last post, I talked about a question that helped guide my early career. By asking those I respected "what do I need to learn to come work with you?" I built a list of technologies and skills that I could acquire to become a valuable team member.

Sadly, I have lost the original list. Listed below are what I consider to be the most important skills on that list. All of them were not really emphasized or offered where I went to college. I prioritized learning them on my own, and I am so grateful that I did. More importantly than my own experience, these are all skills and habits of developers I respect and admire.

Know a scripting language.

You should have a lightweight universal language like bash, Ruby, or Python at your fingertips. Use it to solve repetitive or tedious tasks: renaming a giant folder of files, backing up your photos, launching all the files and folders you need for a project in the morning, etc. Look for an excuse to use it and soon you'll never look at your computer the same way again.

I am constantly writing little scripts to do my work for me. It's because of this advice. Today I used scripts I have written to:

• Automatically resize and position windows the way I like them.
• Switch between apps effortlessly.
• Search through my plain text notes.
• Connect to AirPods.
• Focus a video call.
• Clip highlights from web pages for processing later in Drafts.
• Save those clips from my phone to a specific format in Dropbox.
• Build this blog!

Once you start using little scripts to automate a single repetitive task in your life, you'll see more possibilities… and there are many ways this is useful at work: build tasks, make files, environment setup and tear down, tests… it's all scripts.

A great way to acquire some knowledge of a scripting language is to use it to solve some projecteuler.net or adventofcode.com puzzles. Not only are they fun and a good code challenge, but there are large communities to learn from and see other people's solutions.

Master a text editor.

Pick a text editor that's universal enough to write in any programming language. VS Code is a good choice. In the old days I would have said emacs or vim. Y'all know which choice I made.

You can start with learning how to do the following without thinking… probably using keyboard shortcuts:

• Open (fuzzy find) and save files.
• Autocomplete words and close parentheses.
• Join lines, split.
• Reformat indentation on a file.
• Find and replace across files with regex.
• Jump to errors or uncommitted changes.

Learn to pay attention to what you do on a daily basis in your editor. One at a time, find the most efficient way to perform these common tasks. By investing a little time today, you will save yourself hours and days of future productive time.

Use a debugger.

Especially with the contrived problems you encounter in school it is often enough to try every combination or method possible until the squiggly red line goes away.

We've all done it, there's no shame. But there is a better way. You can use a debugger to help you read through actually understand the state of the data as it moves through the code.

If the language you use has a debugger, learn how to use it. At very least, you most likely do something web related, and you can learn the debuggers built into dev tools in browsers. You should be comfortable with setting breakpoints, conditional breakpoints, stepping through the code after a breakpoint, reading the state.

If you are feeling extra adventurous, learn about strace. :)

Use git, and craft good commits.

(I recognize that git isn't the only game in town, but it's a pretty big one.)

I'd be pretty surprised to hear of a good job in programming that didn't involve using source control. You will work with code. You will work with people. The two intersect in source control.

First you should learn to craft a good commit¹. Then you should learn how to revise a commit or set of commits that need to be rewritten.

A good way to start thinking about commits is to write change sets that have no side effects. If your commit says "rename foo to bar", you shouldn't be also chanting the indentation or checking in a dependency file.

I have recently revised my "living essay" at evantravers.com/git, there is a lot of useful stuff in there.

Study writing.

Programming code is made of words that are evaluated by computers, but they are also read by humans. The computer never misunderstands, but people often do. They say that naming is one of the hardest problems in programming… and that's not because of computers. It's because of people.

You are going to spend your entire career writing prose to be read by humans. You will write human-centered code, commits, documentation, emails, and chat messages. Learning how to edit yourself, to thoughtfully phrase a request so that you minimize back-and-forth, to write documentation that is clear and concise… this is the study of a lifetime. Whether your work is understandable or frustrating depends directly on your writing ability. Developers that recognize this and are intentional in this area reap substantial rewards.

Here is an incomplete list of places to start learning:

• Learn how to ask good questions.²
• Learn to lead with the point. ³
• Learn how to proof and edit your own writing. ⁴
• Be intentional and thoughtful in communication.⁵

This list is always incomplete.

There's so much more to learn! This career path is branching and ever-changing. If you like to learn and grow, you are in the right place.

I had to cut a huge amount out of my main list⁶. I don't judge them to be as universally helpful as the five above.

If you have thoughts or comments, strongly feel that I included something useless or that I left something out, feel free to comment on twitter.