We developers tend to be a bit elitist. It’s part of our culture. Think about it. Programmers strive to be the “top coder”. Companies want to hire “A” people. Everyone knows that the “best” developers can write a thousand lines of code while the average one is still getting his first cup of coffee in the morning, (and we secretly wonder if it’s really true, and whether we’re good enough). Hackathons reward the best teams and projects, subtly implying that “best” means the ability to come up with a brilliant idea and demonstrate it in 48 sleepless hours. Developers want to work for Google or Facebook in part because we all know they hire the very best.

Our culture may be elitist, but it’s not exclusionary. Anyone can learn to code. Everyone should learn to code. But, and this is the elitist part – the expectation is that all of these beginners should strive for excellence. They should learn “real” programming languages, like Python, Ruby, Haskell and C#. They shouldn’t stop until they too are the best of the best, with expertise in all of the latest languages, tools and technologies.

And what of those who just learn a little bit, or the wrong bits? Those who study PHP to support an old web site? The IT tech that learns to write BASH or PowerShell scripts? Or those who learn to write SQL stored procedures or, God forbid, BASIC or VBA! Well, they’re not “serious” programmers. Not really.

Occasionally a platform vendor has the radical idea of creating a programming environment designed to allow ordinary people to develop their own software solutions. The theory is that with such a tool, vast numbers of ordinary citizen programmers will rise up and create all kinds of applications, solving a myriad of business problems without having to turn to those elite, and presumably very expensive professional developers.

The last time this happened was in the 90’s, when Microsoft created Visual Basic. Legions of citizen programmers created large numbers of custom applications and solutions. Kids used VB, Grandparents used VB. Even managers used VB. Most of the code they wrote was awful, full of global variables, goto statements, and not a hint of object oriented programming, even after it was supported by the language. But it was fast and it was easy, and even the most elitist senior programmers were often forced to use VB because it was so incredibly productive compared to anything else. Fortunately for the professional development community (and unfortunately for everyone else), Microsoft dropped Visual Basic in favor of Visual Basic .NET, which was and is a serious professional development language (though some won’t admit it). VB .NET was complex enough and hard enough to challenge even the best developers, and to scare off the citizen programmers, most of who vanished to do whatever it is that non-programmers do.

Visual Basic caught the serious development community by surprise. Even now most have forgotten that for a while it was the most popular programming language on the planet. You may think that kind of thing can’t happen again, but it’s happening right now. This time the subversive company isn’t Microsoft however – it’s a company you may have paid little attention to – Salesforce.com.

I know that many of you will just dismiss this. The first reaction of almost every serious programmer I’ve mentioned this to has been “Salesforce, they’re just a CRM application”. Even IT folk look at it with suspicion – a cloud based service that they’re force to deal with because someone in the sales department signed up for it. Then I tell them that no, Salesforce has evolved into a software development platform, and the look I get is a cross between skepticism and pity – I can almost see their respect for me as a developer fade away.

So I talk about the challenges that real technologists face when working with data. What do you have to do to connect your application to a database? How do you map database fields to language constructs? Do you use strong typing? Or loose typing with a lot of error handling. How do you handle changes to the database schema? What steps do you take in the application to deal with the possibility that the schema may change – a table dropped or field modified or deleted? Do you wire things up dynamically, or do you use tooling, wizards and code generation to build the plumbing, and if so, how do you ensure that it remains up to date when schema changes occur?

Think about what you do to connect your user interface layer to the application. How do you adapt the display to different field types and validate the data? How do you handle concurrency and transactions?

Think about what you do to secure the data. How do you handle users, roles and profiles? How do you control access to records and fields, and how do you authenticate users? Don’t tell me it’s easy – if it was we wouldn’t read every other day about a major security breach.

How do you allow for end-user configurability? Do you embed a macro language? Or just build very complex configuration systems with large numbers of settings? Or do you just implement a solution and plan on endless iterations to adapt the system as needed?

These are all tough problems, and tough problems call for serious professional developers. The elite. The best of the best.

Except on the Salesforce platform, where anyone can program, because these problems don’t exist.

• When you add tables or fields to the Salesforce platform database, they appear in the language as objects with properties, already strongly typed to the correct data type.
• If you reference those objects and properties anywhere, the underlying tables and fields can’t be deleted or changed to an incompatible type. The platform creates and enforces data integrity.
• When fields are displayed on the user interface, which is easily customizable without programming, validation and the correct user interface for the fields just happens automatically.
• Security is baked in – if a given profile isn’t allowed to access a table or field, they just quietly disappear from the user interface for users that aren’t allowed to access them. That’s applies to forms and reports (reporting and charting being built-in as well).

And as for the programming itself, most of it can be done using interactive process builders, whether it’s creating a sequence of screens and operations, or more complex logic. You can define complex solutions using drag and drop flowcharting tools and wizards – the kind that you sometimes see used to teach kids programming, except much more powerful and flexible. And if you somehow aren’t able to perform the task at hand using the interactive tools, you can always write code in a Java-like language they call Apex.

And as the final kicker – almost everything you build can work on any type of mobile device with minimal added cost or effort.

It’s so insanely productive and effective that large numbers of citizen programmers have been turning to it to build all kinds of amazing solutions, without needing to turn to professionals at all.

Many of you reading this will dismiss it. You may argue that the Salesforce platform isn’t suitable for every type of application, or that the pricing model isn’t right for every type of application. And you’d be right – but so what? Can you name any platform that is right for every type of application?

To date, the Salesforce world of citizen programmers had just barely touched the elitist world of professional developers. Only a relatively small number of us play in both worlds. But there are two reasons why it is worth your while to learn about the Salesforce platform.

First, because like Visual Basic of old, when it comes to a wide array of business applications, it’s far more productive than anything else out there: And second, because unlike Visual Basic programmers of old, citizen programmers on the Salesforce platform make good money. Really good money. Seriously – a Salesforce administrator with basic certification can make a good living wage (and that’s without a college degree). The average senior Salesforce platform architect/developer is probably making more than you are.

Go to a Salesforce conference or user group meeting. You’ll see them – the citizen programmers. Many of them struggling to learn. Many of them creating custom solutions – some good and some truly awful. And you’ll see a handful of us – computer scientists, database experts, polyglot programmers. Serious developers, who’ve abandoned the elitist culture for that of the citizen programmer. We help teach and guide them. We come in to clean up the mess when they’ve built something that doesn’t work or is unstable. We have a lot of fun – the Salesforce platform offers its own set of unique challenges. We get paid ridiculously well for our services. And there aren’t nearly enough of us to go around.

So what are you waiting for?