Some of the differences from the previous articles were not as obvious, or even as painful, as the one I've left for dessert - the differences in tools and the development process itself. I believe that you already have a big list of things you've noticed so far concerning this subject, so I'll highlight only some of them below, along with some of the ways to overcome the potential issues.
Project organization
Let's imagine one situation and take The Welkin Suite IDE for an example. The Welkin Suite is a complex .NET application with more than 5000 C# files, which are separated into 113 projects with a very strict folder structure. Let's assume that one day we say to our team of 8 developers that from now on, everything should be organized in a single project, and that only the files of the following types can be organized into these folders that are allowed - "Classes", "Interfaces", "Resources", "XAML", "Images". What do you think their reaction would be? I will tell you what I would do, I'd quit, really 
. And at the very least, this was my first thought when I switched from my hospitable .NET project, to a relatively small Salesforce project that had just about 200 classes. I was horrified to look at Salesforce's standard project structure with separation by types... and what made it worse was that there was no way to change it... To be honest, this was the starting point of the development of The Welkin Suite - I wanted my favorite IDE back, which was doing everything it could to make my work as easy as possible.
But jokes aside - indeed, Salesforce truly does not provide any options to organize your project structure in a useful manner. However, you can read an article in our blog, which describes in detail how this was done in The Welkin Suite, and I am guessing that you already know how to organize your projects in the best way for you.
Cloud-based tools
Another thing that you'll immediately notice is the number of cloud-based tools for Salesforce development. While we believe that "no software" approach for end users is great, we don't believe that anyone can develop a Visual Studio IDE on the web - and make it work in the browser. Why is this so important to us, you may ask? It's because a cloud approach requires some simplifications, and it is less efficient in terms of resources, while an IDE should provide a lot of different options and information, and many of them are resource-intensive. This is why we're not developing in Sublime Text or vim for .NET, but use Visual Studio, or at the very least MonoDevelop, where hundreds of their features are always ready and within reach.
This is why we believe that developers should primarily work with standalone applications, the standalone applications just provide the best IDE experience, and they also help save time and money. There are a couple of standalone development tools available for Salesforce development, starting from the extensions for text editors, Eclipse or IntelliJ modifications, and up to the Visual Studio-based The Welkin Suite, which we have built.
Isn't it familiar?
Lack of debugging options
For a very long time, Salesforce development was very tricky in terms of troubleshooting, so if you're entering this world right now - you're doing it at a very good time!
Previously, Salesforce's debugging options were limited to that strange approach, which involved you entering something like "Console.debug("Variable X="+x.ToString());", and then reading tons of log files. However, I must admit that these Debug Logs are absolutely great, and provide so much helpful information, that it's almost easy to troubleshoot something - but just "almost"...
Obviously, it is a very complex and challenging task - to allow us to debug something in a multi-tenant cloud environment. And yet a while ago, Salesforce started providing Apex Debugger functionality as an addition to your Salesforce license for some additional cost. That's great, but it is not always possible to pay for it, as well as it is not always possible to use this debugger due to some limitations.
There's a workaround for this - use all the information provided by Salesforce's Debug Logs set at the highest level of details, analyze them, replicate the execution process, and enjoy "Retrospective Debugging". This way, you can get as close to the proper debugging process as possible, without anything additional required from you.
No local builds
We've got used to the fact that we can always build our solution locally, and quickly check how our changes influence the application... Well, "quickly" compared with C++ applications, which are compiling and linking for ages. But if we're talking about average applications - depending on the complexity and coupling of projects in your solution, it might take from 1-2 minutes - and up to 20-30 to do the full rebuild.
However, Salesforce removes this option completely - there's no chance to build your changes locally, or to test something locally (this means you can enjoy movies or books while flying, because you need an internet connection to test anything). This might seem as a very big disadvantage, but it is not. This approach is somehow close to the interpreted development languages, as you don't need to rebuild the full project to see your changes. If you've changed one file, you only need to send one file to Salesforce - and this won't take more than 20 seconds (while averaging aobut 3-5 seconds). This means that for most of your changes, you won't spend more than 20 seconds in order to get your code up and running on the cloud, and this is amazing!
There are lots of other differences, disadvantages and advantages between the tools and development process for Salesforce - but we'll leave this adventure for you to set off on. And yet, for starters, you can find the solutions for many of the nasty things in this great "infographics".
To be absolutely honest with you, it would have been almost impossible for me, being a former .NET developer (who switched to Salesforce 3 years ago, and who went along the same path that you're going on right now), not to of somehow promoted the IDE, which our team started building in order to combat these very pain points in other tools that are currently available. I am sure now that we are at the end of this article, not only will you forgive me for this promotion, but you might just thank me.
Your comment may be the first