As a software engineer, here are some tools that have saved me a huge amount of time

I recently answered a great question on Quora: "As a software engineer, what are some tools you use that save a huge amount of your time?" The answer seemed to resonate with many readers, as substantiated by the 33k views and 100+ upvotes it has accumulated over the first few days since being published. I'm republishing it here since it's a topic likely to be of some interest to GitClear's audience as well.

My approach to identifying the best developer tools has evolved significantly over my past 25 years spent coding. When I was a junior developer, I would have excitedly rattled off a list of at least 10 different tools that saved me seconds here and seconds there. Back then, I was a tools enthusiast. But then I met the developer who would go on to become the CTO of our company. He transformed the way I pick my tools, effectively converting me from a tools enthusiast to a right-tools enthusiast. Allow me here to briefly describe his methodology before I dive into the five tools I most strongly recommend.

This guy is the prototype for what Paul Graham was referring to when he said you want to "hire someone who's an animal" at programming. I've always found code measurement fascinating, and before I worked with this guy, I'd measured that I was closing about 3x more tickets than the next best developer at the small company I worked at (more a reflection of their hiring than my prowess, but that’s a longer story). Nowadays, I have the tooling to quantify how much productive output our developers are generating (more on that below), and this guy beats the next best developer on our team by more than 2x. Compared to the bottom 25th percentile of productive developers on our team, he averages 7x more code written. He's unfairly smart, with an incredible memory for code, which helps. But he's also obsessed with how tools beget productivity. He’s the guy that knows every hotkey, and puts up with zero BS when it can be time-efficiently automated.

On a day-to-day basis, he uses the same small set of tools I'm going to describe below. This opened my eyes to how the most productive developers aren't spending their time trialing every new tool that might save them seconds per week. Instead, he selects his toolkit very carefully, and then learns them at an incredible depth.

This is in stark contrast to some of our least productive developers that we've let go over the years. A common thread I observed among these underperformers was that they tended to be what I'd call "IDE enthusiasts." Every few months they would test drive a new IDE (Sublime Text today, vim tomorrow, Atom next month, emacs the month after...). They always had strong opinions about how their latest IDE was transforming their workflow. Except that our developer productivity stats never seemed to match their enthusiasm. The story the stats told was that these developers were paying an immense opportunity cost as they moved from tool to tool, losing all the accumulated knowledge of hotkeys and shortcuts they'd configured in their previous IDE. The longer they stayed on this treadmill, the less time they had to, you know, do work.

I want to be like the programming animal. So I've come to embrace a "less is more" philosophy to tooling. If you select your tools with the utmost care, and take the time to learn their hotkeys and nuances, you can become incredibly efficient with just a few strategic picks. Especially in 2019, when the tools that are available are so damn good. So, without further ado, these are the five most-used tools [1] on our team:

Any Jetbrains IDE (in our case, Rubymine and Webstorm)

The attention to detail applied by the Jetbrains team never ceases to amaze me. Case in point: a dropdown they provide if you click Help -> Productivity Guide. Here, they offer a stack-ranked list of the features you use most often (!). I can't imagine any other IDE conceiving of such an esoteric feature, let alone implementing it. But thanks to their dedication to details, I can give you the exact list of which Rubymine actions are saving me the most time:

The Rubocop feature atop the list is a red herring — here’s a quick summary of my most-used actions from this list:

• Symbol / file lookup dialog. This goes hand-in-hand with the “camelwords” feature, below. Basically, from any line of any file, I’m never more than 5 or so keystrokes away from the implementation of whatever arbitrary file, method, or CSS declaration I seek. Or if keystrokes aren’t your thing, you can define a hotkey to jump straight to the implementation of the method your cursor is on. Another hotkey jumps back to the original file. This set of functionality is the lifeblood that enables diving into unfamiliar code and quickly becoming acquainted with it. Key to the utility of this is that the search dialog appears instantly, and provides results instantly as one types.
• Use camelwords to navigate to symbol or file. The CTO and I love this functionality so much that we co-opted it when we began crafting our note taking and todo list app. This feature is tailor-made for when you have a vague recollection that you want to jump to the implementation of a method named something like awesome_method_name. You type am into your method lookup dialog, and voila — the Jetbrains IDE suggests awesome_method_name, probably atop a list of other relevant suggestions (e.g., am_I_the_method_you_were_after).
• Syntax autocomplete. This one is table stakes for any IDE, but Jetbrains IDE shines here by implementing it without lag, and for a very broad set of (configurable) completion patterns.

GitClear

Disclaimer: I may be a bit biased about this tool, since we created it. But the only reason we began the (three years and counting) investment into this tool was because we were desperate for it to exist. Prior to GitClear, the process of reviewing the code our team was writing on a day-to-day basis was a tedious slog. It went something like: 1) log into Github 2) click into repo A 3) read the commit descriptions to guess which commits were implementing the most impactful work worth reviewing 4) discover that the work in the commit we reviewed was superseded by another commit made later that day 5) repeat for each of repo B, repo C, repo D, etc., plus whatever branches our developers were working on inside those repos. Oh, and attend bi-weekly stand up meetings (which break flow state) on behalf of forcing developers to remember and recount what they’ve been working on lately.

GitClear implements the following changes to that tired process:

• All commit activity in one list. A dropdown is provided such that we can browse through all commits in all repos/branches across the company. Or just the commits from a particular organization / team / repo / developer of interest. No more clicking from repo to repo or branch to branch to find which commits were authored over a given time range.
• Commits grouped by content. Generally speaking, if a developer is working on a ticket, we want to see all of the work for that ticket at once. If their first (usually rough) pass at implementing the ticket was superseded by later work, we don't want to waste time reading since-revised code. Grouping commits to hide churned code often reduces the overall code to be read by 30–50% for a given feature. Tickets also automatically group by the Jira they’re associated with, and that Jira is directly linked from the commit group itself. (Bonus: a list of the highest impact ticket per developer by month is provided to avoid recency bias during performance reviews)
• Commit groups visually demarcated by amount of work done. Aka the green bars from the screenshot above. Every commit or commit group graphically indicates how much work lies within it. No more reading the tea leaves of commit descriptions to determine if the commit contains sufficient work to warrant a click.
• Better operation labeling. Github exists in a world where all work is binary: it's either a "line added" or a "line deleted." In the real world, developers move lines, update lines, and find/replace lines. GitClear treats these operations as first-class citizens so we don't have to guess if a line was really added/deleted, or could be more precisely described as a specific operation from the list above.

A nice side benefit is that the tool quantifies developer activity by a single metric, thereby improving transparency so managers can see who's getting how much done. Great for identifying patterns, like meetings that are sapping developer output (and proving quantitatively that a weekly "work from home" day doesn't decrease productive output)

Chrome Inspector

Hard to imagine there's a web developer that isn't already using Chrome Inspector (except those using Safari or Firefox inspector, which are fine too). But are you using it to maximum effect?

Inspector is a classic example of a tool that every web developer thinks they know, but few have taken the time to master. For example, did you know that you can set a breakpoint based on when a certain URL is invoked? Do you know the hotkey to find a method across all of your Javascript files? And have you checked out the performance profiler (which is amazing)?

Inspector has so many nooks and crannies that the average developer might never explore. But if you take a cue from the most productive developers, you find that Inspector can efficiently debug pretty much any web-based method, process, or event. In the hands of an experienced developer, it’s almost always the fastest tool to extract insight about the “why” behind the behavior of your web app.

Stack Overflow

I think this would be considered a "developer tool"? It sure as hell is a tool that changed the game for developer productivity. Hard to imagine there's any reader of this question that doesn’t already utilize Stack Overflow on the daily. But we should take a moment here to remember that, only 10 years ago, the top Google result for many queries came from a website called “Expert Exchange” (the name still makes me shudder). This website became notorious for describing your exact question, except when you clicked through from Google, the answer you needed was infuriatingly blurred out. Reading the answer required you to bypass their paywall. A years-long cat-and-mouse game ensued between the evil idiots running Expert Exchange, Google’s web crawler (which ostensibly required the answers be visible), and developers (who discovered numerous workarounds to bypass the evil idiots). Those were the bad old days.

Now, it's rare to formulate any question that hasn't already been asked in some form on Stack Overflow. It's still a bummer that sometimes the "accepted answer" is provided before the most upvoted answer, but aside from that, this is one of the most time-saving creations God ever bestowed upon programmer-kind.

Ansible, Capistrano

It’s a two-fer, because nothing saps developer time with quite the zeal of devops. Ansible and Capistrano have been essential to reducing the amount of tedious busywork necessary for us to manage our rack of ~30 servers. There's a reason that Joel Spolsky is so adamant about ensuring deployment is a one-step process: the more incantations a developer has to recite to update their site, the less work they're getting done. And the greater the propensity for slight mishaps to result in site downtime… which seriously reduces the amount of productive work that's going to get done that day.

There’s much to gain when every developer on the team has a working knowledge of devops infrastructure. Without it, how are you going to get a sense for the tradeoffs of asynchronous jobs, or how to minimize inefficient database queries? And if you’re handling devops, you owe it to yourself to ensure you’re using a toolset that prevents the need to interact with servers on a one-by-one basis. Ansible is a wonder for its ability to target groups of servers (e.g., “app servers,” “async servers,” “database servers”) and run an action against the entire set with one fell swoop.

Conclusion

Picking the right development tools is an essential step in unlocking maximum productivity potential. But more isn’t necessarily better, my experience suggests the opposite. The most productive developers I’ve worked alongside share a passion for identifying the best few tools, and becoming deeply familiar with them. In my experience, there’s considerable peril in succumbing to the “tool treadmill.” Hopefully this answer might help others identify a new tool or two that they can benefit from on a daily basis.

[1] This list intentionally omits the set of tools we use to measure application/database performance. Those are key to remaining efficient, but are very environment-specific, so not likely to be broadly applicable. Fwiw I'm a big fan of Vivid Cortex and a medium fan of New Relic.

Bill Harding

CEO/Programmer, GitClear

Bill is driven by the challenge of how best to quantify valuable questions that defy quantification. It's possible this instinct may have been awakened in Bill at age 14, when he won a soft, stuffed bunny at the orthodontist for guessing the number of jelly beans in the gumball machine.