On the Salesforce Stack Exchange, a lot of moderation is performed directly by the community,
Earlier this month, the oft outspoken Jeff Atwood wrote a blog post entitled "Please Don't Learn to Code" which was met with something of a furore, though largely because the message didn't appear to come across as actually intended. Jeff followed up explaining his message more clearly, but I do understand what prompted him to write the original article; over the last few months I've seen more and more tweets and articles highlighting websites such as Codeacademy, encouraging people to learn to code, which is in itself, I believe, a good thing™.
What I don't particularly agree with is the sentiment of some of the articles I've read, which seemingly suggest that learning to code will make you a bona-fide, professional software developer, and it's something that is easy to pick up. It isn't. Learning to program well takes perseverance, cursing, learning and above all, considerable amounts of practice — you will never stop learning, ever, but I can practically guarantee that if you catch the bug, you'll never want to stop. This debate is not what I want to discuss today though; instead I have been prompted by it to talk about what you need to learn if you do want to become a developer on force.com.
So let's get started, how do I write a trigger? I need to learn Java right?
This is the kind of question I've seen asked on both StackOverflow and on the force.com developer boards, and more often than not it's been asked by somebody who does have some prior programming experience, but hasn't worked on the Salesforce/force.com platform before. A lot of the time when working on a new platform, getting stuck in and following some programming tutorials is the best way to get started, but here it doesn't really hold true. For example, consider the following requirement which has been handed to you, the developer, by a user who has identified a way in which their productivity could be improved.
If field X on the Contact record has the value Y, then check the checkbox Z.
Right, let's fire up the developer console, create a trigger to fire after contact records have been inserted and updated and then.... whoah, drop the anchor. Find somewhere comfortable to do some reading, and start tackling the Force.com developer workbook, specifically Tutorial #4: Automating Processes Using Workflow. Still going to write a trigger? Probably not for such a simple scenario, since we can do it without code which makes the solution more maintainable (as you don't need to be proficient in Apex to update it), means there is no test coverage requirement and helps keep your Apex workspace nice and clean.
All Contacts have child records called payments, and the sum of all a Contacts payments is needed on the contact record.
This one seems a bit more complex. We could write a trigger which operates on the payment object, after all types of operation, potentially leveraging aggregate SOQL to do the summation automatically. Alas, such effort could potentially be expended as needlessly, as the thing to do here would be to first check whether the hint contained within the word 'child' actually indicates the presence of a Master-Detail relationship. Should that prove to be the case, then a Roll-Up summary would be more than sufficient to satisfy this requirement, and of these two solutions, it's easily the simpler to implement.
As you may have already surmised, I'm not about to write an introduction to Apex, but hopefully I have succeeded in convincing both those new to programming but familiar with the platform, and those familiar with programming but new to the platform, that development on force.com really does begin with clicks not code. Despite the two examples provided being simple in nature, I believe they demonstrate that grounding your knowledge of the platform in the declarative aspects of it can make your life, and your org, simpler. It is important to note, however, that there is no hard and fast rule; a trigger will often be simpler than a multitude of validation rules and workflow updates, but comes with it's own baggage. For instance, something that often catches new developers out is the need to 'bulkify' their code, both to handle all the records passed into a trigger as well as to handle those records and stay within the enforced governor limits.
Your greatest asset as a force.com developer is knowing when to use clicks and when to use code, and when you may need a combination of both. This is reflected in the two developer certifications available, with the developer certification focusing almost exclusively on the declarative side of the fence, and the advanced developer certification focusing on the Apex and Visualforce side. So should you learn to code on the force.com? Yes, but be sure to learn about the declarative features available on the platform first; with knowledge of both aspects of the platform, your chances of knowing where the line between the two lies only increase, along with your chances of a successful, robust, and expandable implementation.