VBA Serenity

Greetings and salutations, my fellow VBA-fearin’ congregation. Evangelizin’ Jeff here, spreading the good word about everlastin’ VBA serenity. You may remember me from mah preeeevious sermons such as Tables, PivotTables, and Macros: music to your ears and Big trouble in little spreadsheet. Well today, I’m going to praise the work of a high-yah pow-wah.

Our most pious Brother Jon Peltier (who’s fine presence is to mah left) broke his vow of silence over at the PeltierTech monastery to make a most inspirin’ observation during his recent confession Highlight a Specific Data Label in an Excel Chart:

Because I’ve been doing a lot of coding lately, my first thought was an approach using VBA. Then of course I came to my senses, and worked out a non-programmatic approach.

If possible, it’s usually advantageous not to rely on VBA for such tasks.

Hallelujah, brother!

My visionary brother is right: if there’s one rule of VBA that you should religiously observe, it’s to let the application be the application, where ee-fishin’ tah do so. A whiles back, I jokingly spoke it alike this:

The serenity prayer for Excel:
Lord grant me the VBA skills to automate the things I cannot easily change; the knowledge to leverage fully off the inbuilt features that I can; and the wisdom to know the difference.

(And I particularly chuckled at Excel Ninja BobHC’s response: You been on them tablets again.)

This sentiment is echoed in the commandments given us in Professional Excel Development (written by those latter-day-saints Bovey, Wallentin, Bullen, and Green):

This Good Book evangelizes that Excel developers “…shalt be divided into five different categories”:

1. Basic Excel users, whom generally use Excel for fairly simple tasks, but as their exposure to Excel grows, so does the complexity of their worksheets and use of complex worksheet functions, PivotTables, and Charts.
2. Power Users, whom have a broad understanding of Excel’s functionality, and occasionally use snippets of VBA from the Net or via the Macro Recorder, but their code tends to be messy, slow, and hard to maintain.
3. VBA Developers, whom make extensive use of VBA – perhaps too much…to the point that they tend to use VBA to tackle practically every problem.
4. Excel Developers, whom realize that the most efficient and maintainable applications are those that make the most of Excel’s built-in functionality, augmented by VBA where appropriate.
5. Professional Excel Developers, whom know more languages than your typical Babel Fish.

That leap from VBA developer to Excel developer is worth striving for. (Don’t bother striving to be a Professional Excel Developer…they are so nerdy that they get about as many dates as your typical cloistered monk or nun). Unfortunately gaining the wisdom to jump from that third class to the forth one ain’t easy, and dedicated sermons on this matter are few and veryfar between.

Far too often the likes of yours truly are often so focused on leading you not into temptation and instead down a righteous path, that we simply never take the flock anywhere near enough to temptation so that we might cautiously peer at it from a safe distance and say in our most solemn and hushed tone “That way surely leads to hellfire, damnation, and eternal recalculation”. No siree, I’m afraid we usually opt instead to simply get the flock away from there.

However, help is at hand, sinners. Forums such as our very own Chandoo.org/forum are a great place to get guidance on such spirited matters…particularly if you ask the right question, such as “What is the best way to achieve X using Excel version Y”. But you’ll need to ask an open question based around what you are trying to accomplish, rather than being overly focused on how you are trying to accomplish it.

For instance, if you ask “How can I efficiently achieve X with VBA“ then that is all you will get…answers about the most efficient way to do it within the confines of the particular tool you have specified. Which will often not be the most efficient way. In fact, I’ve lost count of the number of times where someone has asked for a formula or VBA solution to some devilishly complicated problem – and got something devilishly complicated formula or code as a result – when a mere PivotTable would have sufficed. Or when some very simple Structured Query Language (SQL) via the in-built (but antiquated) Microsoft Query interface would have nailed it.

[Aside: SQL is basically a database language use to perform the database equivalent of lookups and to crunch numbers, or to conditionally join large datasets based on multiple complex conditions. SQL can be directly leveraged by Excel with minimal programming. Heck, you can use SQL to do stuff with NO programming whatsoever via Microsoft Query – a handy (if ancient) little interface bundled into Excel that will look familiar to any Access users. For an excellent Excel-centric introduction to SQL, read Craig Hatmaker’s amazing Beyond Excel: VBA and Database Manipulation blog. Chandoo also has a great guest post by Vijay – Using Excel As Your Database – on this subject. Ignore all the naysayers and unbelievers in the comments who say “Excel shalt not be used a database” for they know not what the point is. Which is that yea Excel doeth speak in SQL tongues at a pinch, and SQL is pure salvation when it comes to manipulating data, be it Big Data, Small Data, or Somewhere-In-Between data.]

Not to mention the miracles even a layperson can perform if they have the almighty Excel 2010 and PowerPivot installed. Or Excel 2013’s Data Model, which lets you mash up data from Excel Tables and serve them up directly as PivotTables with not a VLOOKUP or Macro in sight.

The end of Excel ain’t nigh…

Every release, Excel gets stronger and stronger. Excel 2010 offered us sinners significant improvements over previous versions…giving us things like Slicers and the free PowerPivot add-in. Excel 2013 takes a giant leap forward in allowing us to leverage off of inbuilt functionality to do things that we would otherwise require tons of complex code and complex formulas to achieve. Had Excel 2013 been launched 10 years ago, I simply wouldn’t need to have been a-preaching VBA and SQL to as many unbelievers as I have. If we keep abreast of these changes, then as the functionality of Excel ramps ever up, our code can ramp down accordingly.

The bottom line here is this: if thou strive to be a really good Excel developer then thou best get to know what’s behind just about every nook and cranny of the Excel application itself. Particularly the newly prophesied ones (yea the power of PowerPivot compels you,according to that dark preacher Mike Alexander). So go and explore all those mysterious things on the ribbon. You don’t have to master all of them…but it sure does help if you have an inkling of what they all do. Not just the obvious things like Tables and PivotTables, but the more mysterious ones like Slicers, Data Validation, and What-If-Analyis. And also the completely hidden ones like Goto Special. Not only do all those things do things natively that would require many Shekels of VBA code to replicate, but most are completely addressable from VBA to boot. Meaning an Excel Developer can simply say “Excel – do that thing with this data“.

Before you try to bend Excel to your complete command, study it well. No matter how much you want to jump right in tinker with Excel’s very soul, don’t discount what’s effectively printed on the outside of the box. If you do, you’re just another lazy devil writing hellish code.

Feel free to leave your own theological questions and musings in the confessional box below. Unless it’s to say that you don’t like Pokey LaFarge. Keep that to yourself. Because I love ’em. Saw them live in Wellington a couple of weeks back. Definitely worth checking out if they come to a town near you.