What secrets are your dev tools keeping from you?

Have you ever been using your favorite IDE or perhaps the stand-alone code editor you fire up day-to-day and accidentally chosen a menu option that you had known was there but had never explored, only to have its usefulness blow your mind?

Or maybe you've come across documentation on a feature, class, or method that had been in your favorite programming language for ages, and which provided an easy way to do something that had previously been a real struggle for you?  Maybe you almost felt silly when you looked at how you had been doing it before.

Do you know how to use your dev tools
appropriately and effectively?

Today, I'm going to cover some simple techniques I use to continually find new facets of my standard tool set and reap the benefits.

I find that, primarily, these boil down to 3 main activities:

• Exploring the edges
• Gap analysis
• Task-driven research

Are you using your development tools to their fullest potential?

In technical work, it's very easy to fall into the rut of only working with the tools and features you know.  After all, they've served you well.  You've done some darn good work with those tools.  While sticking only with you know might work in the short term, it's ultimately going to prevent you from improving at your craft.

I'm not just talking about obsolescence.  Sure, if you only use the same old tools for long enough, you'll find yourself being treated like a Cobol programmer in a roomful of Node.js fanatics.  No, this is about more immediate missed opportunities.  The old saying about having only a hammer makes everything look like a nail definitely applies here.

If you don't take some time periodically to discover what's available to you in the tools you use everyday, you are missing out on techniques and abilities that could have saved you time and maybe even increased your work product's performance.  You are short-changing yourself in ways you may never know.

This brings us to the first of the three activities that I nowadays practice almost habitually:  Exploring the edges.
 
Taking some time periodically to simply "explore the edges" of what you know about your tools can pay huge dividends.  The time-savings of discovering the way your programming language of choice has for processing XML, for example, can allow you to choose the best option for a particular situation.  Didn't know that most languages typically have several different methods for XML processing, each optimized for a certain context?  It's time to check them out.

Learning the more advanced code navigation and code formatting features of your favorite editor can save you hours of work time cumulatively over the course of a project.  Have you ever tried holding down the Alt-key and selecting text in your editor?  Some editors have a pleasant surprise.  Can you say "Column Select"? (More on that here: http://stackoverflow.com/questions/1802616/how-to-select-columns-in-editors-notepad-kate-vim-sublime-textpad-etc-an)

This isn't limited to technical tools actually, but to just about anything. The other day I showed a co-worker the Title Case text feature hidden in Word's format menu.  Another team member heard us talking and dropped in to see it also.  These little time-savers add up to big productivity gains and boost our confidence with our tools, as well.

So what's the best way to explore the edges?

Truly, the best way to dig into those areas you don't know yet is to just start poking around.  Go to those menus that you never use. You know, the ones you are always too busy to click on.  Check out the options and see if you can learn what they are for through context.  If they suggest a deeper capability, why not read up on it? Indulge your curiosity.

Having explored the edges for a while and seen what lies hidden in plain sight, you can then move on to the second of my techniques for flushing out new and interesting features of familiar tools:  Gap analysis.

The concept of gap analysis is usually applied to business results as compared to a benchmark.  The "gap" in this case refers to the difference between what we are getting and what we want, as regards a particular system or business process.  If you happen to be familiar with more than one tool of a particular type or more than one programming language, it can also be helpful to use "gap analysis" by using your knowledge of one tool as a benchmark against which you can compare the other.  If language X provides feature Y, for example, then where is feature Y in language Z?

For example, I was recently working with some Javascript code involving several lists of objects and was attempting to process them in certain ways.  While we use JS frameworks that make this sort of thing easier (JQuery/KnockoutJS), I found it odd that I didn't know of any way to process an array of JS objects in plain Javascript apart from a simple for-each loop. My Javascript experience runs back to the mid-nineties when it was originally shipped with Netscape browser as "Livescript," and I've periodically updated my knowledge of it since then.  Somehow, though, I missed the introduction of Array.forEach with EcmaScript 5 which accomplishes just what I wanted.

So, how did I know to even look for this?  Primarily, it was my knowledge of other programming languages, namely Perl, Java, and C#, all of which have either built-in functionality or readily available tools that make just this kind of list processing really easy.  I often find that I hesitate to code something when I get a feeling that there just has to be an easier way.  I start casting about, trying to find the bit of missing knowledge.  Finding the easier way may take me a few minutes more, but the pay-off in future productivity easily earns back the lost time plus interest.

Finally, having Explored the Edges and tried Gap Analysis for a bit, it's almost automatic to pick the third and final habit:  Task-driven research.

Once you've exhausted the options right in front of you, task-driven research allows your day-to-day work to suggest new explorations.  Don't you wonder if there's an easier way to do that thing you just got assigned and are planning to code from scratch?  Surely someone's done it before.  Maybe there's even a way to do it hidden in the lesser known reaches of the framework you're already using.

Aren't you sick of copying and pasting the same boilerplate code over and over again?  Maybe your editor has a templating ability you haven't discovered yet.  Or maybe there's a templating technique that doesn't rely on a specific editor at all.  Let your current needs and interests suggest where you should explore next.  Use this as an opportunity to scratch an itch.

I've advocated "tinkering for fun and profit" before, but this is a bit different.  "Tinkering" implies experimenting and exploring with no defined end goal and usually no direct application to your daily work.  This exploration is a purposeful activity, even if the process is a bit organic and seemingly haphazard.  The goal is increase your knowledge and skills related to your tool set and its applicability to your work is guaranteed, because you are enhancing your understanding of the things you use every day.

Let's recap the main points:

•  Sticking with what you already know well about your tools can hold you back from learning new and better ways of working
• You can easily learn more about your everyday tools by:
• Exploring the edges and digging deeper into what's right in front of you
• Performing a gap analysis to let your knowledge of one tool suggest the existence of solutions in another
• Use task-driven research to let your work point you toward new horizons that you can explore to find even more new techniques and features

Schedule some time to do this each week, even if it's only a few minutes, and you'll begin to see payoffs almost immediately.  I can't predict what secrets you will uncover, but I am confident that it will "up your game" and be yet another step toward becoming an Above Average Programmer.