Join an online tech community

Dear new developer,

A big part of your job is keeping up to date with new technologies and happenings in the tech world. This can sometimes be a distraction, because there is all kinds of new stuff coming out all the time, whether from big companies releasing new tools or platforms, people publishing interesting code or articles on their experiences, or marketing from smaller companies. I avoid this distraction by relying on a community to do some filtering for me. Obviously that means that you need to find the right community, otherwise the filtering won’t be effective.

If you know the exact type of technology you want to focus on (say React Native or Haskell for web development), you can sign up for an email list(s) related to the projects. Or you can go to github and start to follow the issue lists. Or if you know people involved in the project, you can follow them on Twitter. Matt Raible, a prolific developer and blogger, once mentioned that he learns a new technology by unfollowing everyone he is following on Twitter, then following only people talking about the technology, so that his Twitter feed is rich with focused information.

However, if you aren’t sure exactly what to focus on, a more general community might be a better fit. These ebb and flow over the years but they also cross pollinate, so if you join one and a few years later it feels like it is not as active, be on the lookout for the up and coming community to jump to.

Slashdot was the first focused online web based community one I ever took part in. I enjoyed the discussions and linux focus. Recently I’ve moved on to Hacker News, which has a nice mix of technology, science business and politics that I enjoy. But there are other great options like Reddit (where you can find any subgenre you want, but you may want to stick with the big reddits like /r/programming), Stackoverflow (for programming q&a), and lobste.rs (which is less business and more technology focused).

Whatever community you join, whether it is a specific project or a general link sharing site like Hacker News, make sure you actually become a member of the community. Just like the value of a meetup is in who you meet time after time, visiting an online community just once is unlikely to be valuable. And be especially wary of self promotion (this Reddit page has some great guidelines about how to be an effective member of an online community, but seek out such guidance wherever you land).

Once you find and join a community, take part in it. Comment, submit links that you find interesting, and visit it. Be ready to be offended or hurt by some comments, especially if you say something dumb. I have definitely said dumb things or spoken on topics that I wasn’t fully informed about. I feel a flush of shame, leave the community alone for a few hours,and then come back and apologize or acknowledge my mistake. It’s unpleasant but part of the package.

The more pleasant part of the package is being exposed to new things. If it solves a problem you see, you may want to discuss bringing a new technology or piece of open source software into your work. Your work may have policies around new technology, but it never hurts to bring it up and discuss whether it may be applicable. You also may find interesting commentary and perspective on the technology you are already using at work, and sharing that can be a good way to help the team get better with it.

It’s also fun to occasionally submit something, whether an interesting open source project, an article on your blog, or something else you’ve seen. I’ve done that a few times and it’s nice when a submission blows up and becomes popular. It’s also a nice way to say “thank you” to someone who has written something interesting and help them out–I can think of multiple submissions that were interesting articles written by people I knew and when the submission got popular, the people were thankful I’d posted it.

In summation, find an online community, participate it in, and you will reap the rewards.

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.