Why Consultants Should Learn to Type

$100,000,000,000.

How's that for an answer to the title question? If you're wondering where that came from, the answer's simple. Let's conservatively estimate the size of the consulting industry to be $200 billion^[1][2]. Without adding more people, what would happen if the productivity of people already in the industry increases by 50%? That 50% would amount to $100 billion, and that's the reason I believe all consultants should learn how to type.

Okay, lest my alma mater revokes my MBA, I'll admit right now my posit is a gross exaggeration based on unrealistic assumptions. So I'm off... but by how much?

50% is bogus. Or is it?

"The average person types between 38 and 40 words per minute... However, professional typists type ... upwards of 65 to 75 WPM."^[3] The difference between the professional typist and the average person is simply that the professional typist learned to type. And my adjusted typing speed is 87 WPM, even with a wrist injury.

Nbd, just @martyychang typing on two keyboards at once #how #what #nowristnoproblem pic.twitter.com/rkHLXBTJkB

— Julien Ouellet (@trailsforce) October 26, 2015

#yawn So what? So if you're not typing at least at the pace of a professional typist, consider yourself handicapped. Not in a derogatory way, simply such that you have much untapped potential.

Try an analogy

Take human speech as an example. Here are two clips below from two consultants pitching their firms to win a project. Which one would you hire?

Consultant A


Consultant B


You've probably figured out that it's the same voice recording, with the modified clip slowed to 67% of the original. But isn't the difference obvious? If you wouldn't hire the second guy because he spoke so slowly, why should you settle for the guy who types that way?

Keep in mind that typing is not rocket science. All it takes is scheduled time and practice.

Imagine if

... John the business analyst suddenly produces 50% more:

• Detailed notes from meetings
• Thorough functional requirements
• Accurate and comprehensive documentation

... Jane the app developer suddenly produces 50% more:

• Code
• Code comments
• Regression test automation

... Jill the project manager suddenly produces 50% more:

• Personalized stakeholder communications
• Risk reports and mitigation strategies
• Next phase project proposals

... everyone shared and collaborated 50% more on enterprise platforms! (Chatter, anyone?)

The value gained from a 50% increase in typing speed is not proportional. I believe it's exponential. People who have speech impediments tend to speak less. You can guess that people who have typing impediments will avoid mediums where typing is the means to communicate.

And if your consultants, your organization doesn't care to address people's typing skills, aren't you leaving money on the table from your investments in typing-based platforms like SharePoint? Salesforce? Confluence?

Closing thoughts

I believe we owe it to ourselves, to our companies, to our economies, to learn this simple skill that catalyzes collaboration and value creation in the digital age. And if you're a company, teaching your people to type is a one-time investment that will pay lifetime dividends.

The Apex Ten Commandments (in Writing)

For anyone (like me) who couldn't find the slides to The Apex Ten Commandments recording referenced on the Architect Core Resources page, here's the written list:

1. Thou shalt not put queries in for loops
2. Thou shalt not put DML in for loops
3. Thou shalt have a happy balance between clicks & code
4. Thou shalt only put one trigger per object
5. Thou shalt not put code in triggers other than calling methods and managing execution order
6. Thou shalt utilize maps for queries wherever possible
7. Thou shalt make use of relationships to reduce queries wherever possible
8. Thou shalt aim for 100% test coverage
9. Thou shalt write meaningful and useful tests
10. Thou shalt limit future calls and use asynchronous code where possible

And I just have a couple of comments to add for color.

Comments on #7

I haven't tested this hypothesis yet, but... does this commandment still hold with large data volumes? Especially in the context of batch Apex? One certainty is that executing a single query like this is convenient for the developer. But when the query would return thousands of records that reference a small set of parent records, perhaps at larger data volumes a more efficient approach would be to split the query and leverage commandment #6 instead.

Comments on #10

The future annotation is slowly become obsolete with the introduction of the Queuable interface in Winter '15, although general guidelines for designing asynchronous automation still hold true.

Queueable vs. @future throwdown!

At first blush, the new Queueable interface appears to supersede the old @future annotation in Apex, especially now that in Spring '15 you can chain a job to another job an unlimited number of times. Yes, that's right: unlimited.

So, what's the purpose of @future in this new age of Apex?

Let's start by comparing the well known @future limits with Queuable.

@future consideration	vs. Queueable
Some governor limits are higher, such as SOQL query limits and heap size limits	Some governor limits are higher than for synchronous Apex, such as heap size limits
Methods with the future annotation must be static methods	Queueable implementations must be instantiated as objects before the the execute() instance method is called, leaving room for additional job context
Methods with the future annotation can only return a void type	Queueable classes must implement public void execute(QueueableContext), which is how a job is initiated
The specified parameters must be primitive data types, arrays of primitive data types, or collections of primitive data types. Methods with the future annotation cannot take sObjects or objects as arguments.	A Queueable object can be constructed with any type of parameter, stored as private member variables
Can make a callout to an external service
A future method can’t invoke another future method	You can chain queueable jobs. You can add only one job from an executing job, which means that only one child job can exist for each parent job.
No more than 50 method calls per Apex invocation	You can add up to 50 jobs to the queue with System.enqueueJob in a single transaction
The maximum number of future method invocations per a 24-hour period is 250,000 or the number of user licenses in your organization multiplied by 200, whichever is greater. This is an organization-wide limit and is shared with all asynchronous Apex: Batch Apex, Queueable Apex, scheduled Apex, and future methods. The licenses that count toward this limit are full Salesforce user licenses or Force.com App Subscription user licenses.

From the reverse side, what about known limits with Queuable?

Queueable consideration	vs. @future
The execution of a queued job counts once against the shared limit for asynchronous Apex method executions.
You can add up to 50 jobs to the queue with System.enqueueJob in a single transaction.	No more than 50 method calls per Apex invocation
No limit (except in DE and Trialforce orgs) is enforced on the depth of chained jobs, which means that you can chain one job to another job and repeat this process with each new child job to link it to a new child job.	n/a (cannot chain @future methods)
When chaining jobs, you can add only one job from an executing job with System.enqueueJob, which means that only one child job can exist for each parent queueable job. Starting multiple child jobs from the same queueable job isn’t supported.
You can’t chain queueable jobs in an Apex test. Doing so results in an error. To avoid getting an error, you can check if Apex is running in test context by calling Test.isRunningTest() before chaining jobs.

The verdict: Implement Queueable as a standard approach, and only look to @future if for some reason Queueable gives you unexpected or undocumented problems.

Report Folder: Embedded Analytics

I thought it'd be worthwhile to jot a few notes about consistency in managing Salesforce reports designed for embedded analytics. Specifically, help admins quickly identify and find these reports, so that accidental edits can be avoided in organizations with hundreds or thousands of reports.

The idea is pretty simple:

• Put all reports used for embedded analytics in a folder called Embedded Analytics
• Begin all report names with the object label and a colon (':'), so that the target object is immediately understood. For example: "Contact: Activities Last 30 Days"
• Begin all report descriptions with, "Embedded chart showing ..."