Someday, You Won’t Want To Code For A Living

Dear new developer,

I remember the first full time coding job I had. I was able to¬† work on a great team, on interesting problems. I was able to get into the “flow” that is such a magical state. I was paid well. I had free snacks.

I remember going into my manager’s office and chatting with him. He seemed a bit stressed. He was constantly interrupted. He had lots of meetings. He seemed to want to code, but didn’t have time for it.

Me being the naive young optimist, I asked him once why he wasn’t coding. Why would he leave a really fun job for management?

He looked at me with a knowing smile and said something like “one day, you’ll understand”.

I don’t code for a living now. Oh, sure, I write some code. And it still gets me into flow. And I still enjoy it.

But the honest truth is that when I am coding, I have the leverage of one person. As I grow older, I grow more impatient to effect change in the world. The best way to effect change is to have more leverage. Some options for higher leverage:

  • writing
  • project management
  • product management
  • speaking
  • mentoring
  • leading a team
  • managing
  • teaching
  • architecting
  • consulting

Most of these involve communicating about coding (or other technical systems), but coding is not the primary work output. Instead, the emphasis is on knowledge or alignment of a team.

Now there are also code specific ways to get more leverage. Two that I can think of.

  • work on really big systems that have a lot of users (FAANG companies, or something similar).
  • work on open source libraries or projects that have a lot of users

If either of those floats your boat, then pursue that. I don’t like the first because I don’t really enjoy the bureaucracy and politics of big companies. I am not a fan of the second because I don’t really enjoy working for free.

By the way, no one says you have to have leverage. I’ve just seen that happen again and again across many companies and many individuals. Part of that might be the crowd I run with, but part of it might be that more leverage typically means more pay.

Your career is long. My guess is that one day you won’t want to code for a living. Enjoy it now, but keep your head up and think about what other areas, focusing on communication or team alignment, might eventually be of interest to you. Learn about those areas. Meet people who are currently doing them, and ask questions.

Sincerely,

Dan

Learn the command line

Dear new developer,

I remember the first time I saw a senior engineer struggle with the command line. He was a new hire and was getting up to speed on a new project. If memory serves, he was trying to get his IDE set up for a java project.

I noticed him with the command line open, trying to remember how to move around directories, and wondered why he was having such trouble. (Probably I felt the same way some developers feel about me when I struggle with CSS or cutting up a PDF or reading C–“how could you be a developer without understanding this?”.) I never talked to him about this, but it cemented in my mind why a new developer should learn the command line inside and out.

It’s a baseline.

The command line interface (CLI) will always be available. Wherever you are (unless you are on an old mac, pre MacOS X, in which case, why?).

Unlike some of the skills I mention above, knowing how to navigate the command line will make your life easier as a developer no matter where you work or in what platform or capacity. It’s a general purpose skill, like understanding how to use version control or learning a text editor.

Understanding the command line and being able to use it has the following benefits. Let’s take a simple task–I need to move a file into a directory, change the permissions on that file, then look through the file for a certain phrase (say, “rosebud”). With a CLI, I can:

  • accomplish the task in less time. I can move files, change file permissions, and look through files far quicker with command line tools than I can with any GUI (graphical user interface) tools. (There are any number of other tasks I can accomplish more quickly, as well.) The kicker is, of course, the first few times I do this, I will be slower on the command line than I would have been using a GUI. This is because you have to learn the CLI and the cues to help you do so are minimal. You of course also have to learn a GUI (anyone who’s ever shown someone a GUI for the first time know that) but there are more cues on what is the right behavior in a graphical context. But once I have it down, the typing the commands will be much quicker than moving the mouse.
  • make tasks repeatable. If I’m trying to move a file, change its permissions, and see if it contains “rosebud”, I can do this once easily in the GUI, using the mouse and menu commands. But doing this task regularly, whether once a day, once a month or once every time a piece of software is released is quickly going to get tedious. I can, on the other hand, do it once in the CLI, and then take the CLI commands and put them into a script (a text file that becomes executable). Then that same set of commands will be run every time I run the script. This may not matter if task is simple (as is my example of only three commands is), but if it is complex, getting it right once and having it run perfectly every time thereafter will be a huge time and energy saver. If executing the task is common, then you will save time because you will run it often. If executing the task is rare, you will save time with a script because you won’t have to remember how to run the command.
  • share tasks with other people. Yes, you could record a video of yourself clicking through a GUI to move the file, change its permissions and look for “rosebud”. Or you could document the actions in detail and send the doc over. Or if you are colocated, you could show them. But it’s much easier to just send someone else an executable script or set of commands that they can examine and run. As long as they have access to the same command line programs, you’re going to get the same results. (Beware different versions of the same command line program, especially if you are using esoteric commands or working on different operating systems.)

Hopefully I’ve convinced you to learn the command line. Now, what are good ways to learn it?

I think that one path is to just jump in. Find the “terminal” program if you use a mac, or the “cmd” program if you use windows. Open it up. Then google for “command line tutorial <platform>” and work through one of those. I always work best when I have a real task, so think of something you do often (for example, opening up a number of files for a project, moving files to a backup directory) and do it once in the GUI. Then do it once in the command line. Then make a script for it. See how that feels. If you are scared of messing up your computer, install a VM or boot up a cloud server (most cloud providers will give you a small server for free for a while). You can’t screw up a VM that you just started, and if you do, just destroy it and start a new one.

Another option is to think about mapping between the GUI/IDE and the command line. Every time you do a task in the GUI or IDE, drop down into the command line and try to replicate that. From something as simple as moving a file to something as complex as a full fledged deployment or compilation of a large project.

As you get more advanced, you have the option of sharing your keybindings between your editor and your shell. Just google “keybindings <editor> <shell>”. I use vi keybindings for my bash shell and it lets me move around the command line with ease and speed. And every time I learn a new way to move around the editor, my CLI usage gets better.

The command line is underneath almost every computer. Learning it will save you time and let you leverage knowledge. Well worth the effort.

Sincerely,

Dan

PS I would be remiss if I didn’t link to this essay about the command line.