The Softwaresmith's Tools

In programming, as in most professions, the tools make the master of the craft. You have to know which tool to use when, and you have to be able to use them well.

My goals in this article are: (1) to act as an introduction to the tools of the trade for those looking to try programming (2) to give some tips to those who are already programming and (3) as a reference for future posts - you should be seeing a lot of these tools in my future posts.

Since this entire post is about resources (tools are resources), there will be no "resources" at the bottom of the post; instead there will be an index to quickly find the section you want.

Without further ado, I humbly present what I consider to be the most important tools for the software smith:

Your Own Brain

You really need to treat your brain like the tool it is: you have to keep it sharp and treat yourself right:

Take frequent short breaks: 10-15 min per hour is a good rule of thumb.¹
Make interruption-free time for complex tasks.²
Get enough sleep (I'm afraid I often fail at this one). The problem for me is, the best interruption-free time is late at night...
Eat well - your brain consumes a lot of energy and the supply needs to be consistent. If you're eating lots of sugar, your blood sugar will be bouncing like a ball and your cognitive abilities will, too.
Exercise - this improves circulation and gives you a nice shot of dopamines, which helps you concentrate better.
Learn new, interesting stuff - "exercising" your brain helps keep it sharp through less interesting tasks.

A Search Engine / Good "Google-Fu"

Most people don't think of this as a programming tool, but, after the brain, it is the most important tool we have these days. When I was learning to program, search engines did not exist. Nowadays, a good search engine is completely indispensable. Here are a few basic scenarios where I need it:

There should be a picture of me applying GoogleFu to a problem here.

Something has broken, and I need more information on how to fix it: has anyone had this problem before? If they solved it, how did they do that? Did they discover a work-around? What does this obscure error message really mean? Before search engines, you would be writing emails and waiting days for responses, or if it was really urgent, paying for expensive long-distance phone calls.
I need the name and/or parameters of some function in some language or library I'm less familiar with. Way back when, you could keep all the references on your shelf. Now, with new languages and platforms coming out several times a year, you would need a whole house just for the books, and a budget to match.
I'm trying to learn some new language or platform, and the guide I'm reading starts referencing technology x and paradigm y that I've never heard of before.

The simplest search sometimes work, but as often as not, you'll need to think of 10 different ways to search for the same thing before you hit gold. Good Google-Fu is important.

Google is still the best, in my opinion, but has actually been going down in utility for me as they've been tuning it more towards my preferences, e.g. "no, I really don't want the Java version of this function, that's why I typed "Python". In quotes. And you're still ignoring it and giving me pages where the word 'Python' isn't present!"

For most of my daily needs, I use DuckDuckGo: I'm not entirely comfortable with the way Google sometimes seems to know more about me than I do. When I'm really not finding anything at DuckDuckGo, I go back to Google.

Touch Typing

Technically this is more a skill than a tool, but I'm still including it: it's really important.

KermitTyping

When I was 14, I decided to learn to touch type. It took about a month, filling at least two pages every day. I was lucky: I was at grandma's and got to practice on her electric typewriter, rather than on my mother's manual. In the 40 years since then, it has paid me back at least 1000-fold. That is not hyperbole, it is understatement.

In programming, more than in most other professions, you need to be "in the zone" to work well. To me, having to look down from the screen to hunt-and-peck just doesn't bear thinking about.

If you don't have one, consider getting yourself a decent keyboard. A laptop keyboard may do in a pinch, but really, you need something better. My main development computer is a laptop, but I have a separate keyboard for it.

A (Powerful) Text Editor

I could fill a long post on text editors alone: this section was taking over half of this post and expanding, before I decided to cut it drastically.

It is fairly likely that at some point you're going to be bopping around in remote shells, installing stuff and fixing problems. When you do, you will need an editor that:

can do everything from the keyboard.
supports advanced functions like keyboard macros
supports multiple windows and buffers, with copy/paste between them.

There are two major text editors that fit this criteria: Emacs and Vim.

The original Emacs was written in 1976 by Richard M. Stallman (yes, that guy) and Guy L. Steele, Jr. (I learned Lisp from Guy at C-MU).

Vim is an Open Source clone of vi, a text editor written to be part of the POSIX specification. Vi was also created in the late 70s.

You should know one of them well enough that you can do buffer-switching and other advanced commands without having to pause to look it up. You should, at a minimum, know how to exit your less preferred editor.

These days, if you know neither, you should probably give the preference to Vim, because some flavor of Vim or vi is on nearly all Linux installations (due to POSIX spec), while this is not true of Emacs. Emacs is my own preferred editor.

Operating System, Shell, and Shell-Scripting

Over the years I've run into a fair few people who were of the opinion that shells are passé, that all you need is the GUI of your operating system and a good IDE, and you never need to touch those clunky old shell's with their impossible to remember commands again.

If you want to be an average programmer and never touch the bleeding edge again, I'd agree with that. Otherwise, Exhibit A: setting up this blog would not have been possible without extensive use of a Linux shell (bash). When the init-script for ghost didn't work for my system, I rolled my own. Not a serious problem when you understand the scripting language and have decent Google-Fu.

"But I work under Windows!" So do I. Windows 7 is still the primary OS on my development computer. I work with a shell open at all times. I have several dozen cmd shell scripts for Windows that I wrote myself to make my life easier. Maybe I should upload the most useful of them and make a post about it. If you would like that, comment below and let me know.

As a developer, your most common choices for operating systems are: Windows, Linux, and MacOS (OSX). I will not attempt to get into the OS wars here. Suffice to say, your choice will be heavily influenced by your target audience and your budget.

Miscellaneous: there are multiple *nix shells, bash being the most common. It can sometimes be a problem getting a script to work in all shells being used. MacOS is based on Unix, so if you're familiar with Linux' bash, the MacOS shell isn't too hard.

A Secure Remote Shell

If you're doing anything with VPS, or even just with a server in your local network, then the need for remote access is pretty obvious. For *nix to *nix you'll want to use OpenSSH - the ssh command and sshd daemon. For Windows client to Linux server, I use putty. For Windows to Windows, Remote Desktop Connection is my choice. I've never really needed Linux to Windows, but if I do, I'll probably just use OpenSSH for client and server, with the sshd on the Windows side running under CygWin.

Browsers

Browsers have morphed into platforms in their own right. The following are the top browsers in rough order of market share:

Name	Logo	Platform(s)	Notes
Chrome		on all popular platforms
Firefox		on all popular platforms
Internet Explorer		Microsoft Windows only.
Safari		iOS/macOS only.
Opera		on all popular platforms

Currently, I try to make sure that all my HTML/CSS/DOM is correctly interpreted by Chrome, Firefox and IE, which covers over 90% of my target audience. When I switch to Linux as my primary platform, I will likely drop IE in favor of Opera.

Here are some other browsers which may be of interest:

Microsoft Edge- web browser that comes with Windows 10. Windows only. Interestingly, as of this writing, there are a number of non-Microsoft browsers in the Play Store that have the word "edge" in their title.
Lynx - text-only browser.

Email Client

As a programmer, you need email, but you probably don't need much by way of extras, so this section is short. Most OSes come with an email client, and many mail providers have a webmail interface. They are generally not complicated.

The company I worked for had me using Outlook ³ with Microsoft Exchange Server for many years, while I used the webmail interface of AOL and a more local mail service for private email. That was acceptable.

Now I've switched to accessing all of my email addresses using Thunderbird. I like this better.

(I have both my own domain and an AOL address. What does that say about me?)

(Secure) File Copy

My primary tools for transferring files are:

FileZilla - A graphical "ftp solution". I use this mostly to update websites.
scp - Secure CoPy, a basic *nix tool. Under Windows I will sometimes open CygWin shell just to use scp to copy a file to/from a folder not reachable by ftp. I should probably look into a native SCP for Windows - I use it often enough.
curl - a data transfer program, supporting ftp(s), http(s), and an insane number of other formats.
Default ftp client - both Linux and Windows have a default command line ftp client.

Version Control

I've been using some type of version control since ca. 1990, long before it became de rigueur - it has saved my butt innumerable times. Even when it wasn't saving my butt, it allowed me to proceed more quickly when making far reaching changes: a simple click or command for backup and after a short pause, I can proceed.

Under Visual Studio I originally used Visual SourceSafe (VSS). There were numerous problems with it, especially through remote access (Darn it, Microsoft! Who doesn't use version control remotely?!). But it was still better than no version control. Later I used Team Foundation with Visual Studio. It did its job well.

For side projects I used to use Concurrent Versions System (cvs), then Subversion (svn). I was happy with both.

Now I use git for everything, it works well on the command line and is integrated into most of the IDEs I use.

File Difference

I find it necessary to look at the difference between files in three cases: (1) I am about to commit my changes, and I want to check that the changes are clean (no debug output, comments cleaned up, etc.), (2) to merge conflicting versions and (3) to review someone else's changes.

Under Windows I still use windiff, which came with the Microsoft Windows SDK, but is no longer supported. I'm going to miss it when it stops working.

Under Linux or when I'm restricted to text-only, I use the standard Linux utility diff.

Text Search

Under DOS and then later Windows I used the Norton Utilities program ts for text-search. After moving to 32-bit, I actually wrote my own replacement - I found it overblown to pay for a program I could write inside of an hour.

Under Linux I use grep, of course

Virtualization / Emulation Software

As a developer for commercial programs, the programs usually need(ed) to run on multiple versions of Windows (or other OS). Way back when, we had to have separate machines for each operating system. Now I use ~~Innotek~~ ~~Sun~~ Oracle VirtualBox. I have Windows in four flavors, Linux in two flavors and even Android (technically also Linux) in three flavors, all on my server. I don't use the server itself for anything else.

When I need a Unix-like environment under Windows, where you can use *nix tools and scripts, I use CygWin.

Integrated Development Environment (IDE)

IDEs generally try to be the be-all, end-all environment that you never have to leave, with integrated text-editing, compilation, debugging and other tools. The IDE of your choice usually depends on your developer platform and target platform.

The most versatile Open Source IDE is Eclipse. You can configure it to target almost any platform, including Windows, but...

If your target is Microsoft Windows, then you'll likely be using Microsoft Visual Studio. It's actually pretty decent for other targets, too.

If you're programming for Android, you'll most likely be using Android Studio

Emacs and Vim - yes, both of these text editors can be used as an IDE. If you're in a text-only remote shell, this can be important.

GDB - not really, but: if while debugging you type Ctrl-X "A", it will enter "TUI Mode", which will allow windowed debugging as if in an IDE, with Emacs-like commands.

I've used all of the above, and am actually pretty happy with all of them.

Compiler/Interpreter

Not going to say much here. There's too many, and the choice is often made for you, depending on what you want to do. I used to make short programs, like calculating the prime numbers under a thousand, in gwbasic, but that has stopped working. Now I usually do things like that in C/C++ using gcc.

Footnotes

1 Article from The Atlantic, 2014 "A Formula for Perfect Productivity: Work for 52 Minutes, Break for 17"
2 This is why you shouldn't interrupt a programmer - The Slightly Disgruntled Scientist
3 Outlook full version, not to be confused with Outlook Express.