is code you can download, review and modify. The moment a third party or a internet based service is involved, there can be on trust.

It's not fear driven development. It's incompetent, obsolete management.

Three issues going on here:

* Not enough IT professionals who can code.
* HR people are still looking for people with 23 years of experience with Ruby on Clouds
* Really awful management that either has no tech experience/education or is someone who sucked at IT who got promoted.

Non developer positions are having issues.
Finding developers is getting more and more difficult.
Devops is growing.

Maybe time to learn to code and not just click away at control panels?

I like to have developers bring in some code they've written and go through it. It's amazing how many developers are just not good at interviewing... until we start looking at code. Oh, and the fakers, well, they seem to never bring code to the interview.

As far as tests go, we use them for people fresh out of school because there is a huge difference between passing a CS class and actually being able to apply that knowledge.

If you like GTD, the best organizer ever is Emacs Org Mode. Because Org Mode uses plain text files for storage, you can use git for storage and have very meaningful history tracking and sync across devices. There are even tools for syncing to third party calendars (i.e. Google) and devices.

There is no difference in parties in how they sell their platforms. Republicans use fear of foreign powers, fear of government, fear of immigrants and fear of loss of financial independence. Democrats use fear of racists, fear of religious institutions, fear of loss of government subsidies and fear of foreign powers.

The biggest difference really is how they view government: Republicans pander to those that fear government and Democrats pander to those that fear the lack of government. The message of fear was beaten by a guy selling hope.

The open source world just hasnt' evolved the maturity to make a universal desktop OS **that people use**

It is more likely that people have not yet evolved to use an open source desktop.

On developers never having access to production:

In many cases, developers are the only people who understand the full application, and in many cases are the only people who can actually troubleshoot a botched install or figure out why things aren't working right in production. Yes, you are suposed to have some kind of QA or staging environment and you are not supposed to deploy bad code, but sometimes things go sideways. In these cases, only a developer who knows the code and any integration issues will be able to figure out what went wrong. Acting like developers should *never* have access to production is a lot like saying "the mechanic should never have access to my car's engine, ever". It makes sense 99.9% of the time, but there is a .1% where your engine is broken and the mechanic can't fix it without getting under the hood. Yes, Mr. System Administrator you can change your oil, rotate tires, and even change wiper blades but fixing a spun road bearing or smoked transmission solenoid is flat out.

On Developers and Access Rights:

There are a lot of developers who don't understand the computer they are developing software on. Usually, they are very BAD developers. Take for instance, a webdev who doesn't know Apache. Instead of using built in tools like mod_rewrite, the developer will build their own tools to do what is built in to apache. Good developers know their platform, often at a level that is much deeper because they take time to read code or API and config documentation so they understand the toolbox they are working with. Often a single line of configuration is more powerful than 1000's of line of code. Developers need to be administrators on at least their developement environments... usually extended to staging there is a large difference in scale between development (a VM on my laptop) to staging (multiple servers) and production (hundreds of servers).

On installer driven software:

It doesn't matter if you use installshield, roll your own RPMs or use Salt, Chef or Puppet. Any way you go you should do everything you can to automate installation. When you automate you reduce the chance of human mistakes in installation process. If you do installation automation right, then a deploy to production can be triggered by anyone with appropriate authority or any automated process with appropriate authority. Having people sit at the console and install software manually should be a red flag that the software you are buying sucks or is incomplete.

In Enterprise-Grade software:

Installatioin should be automated to the maximum extent possible, using the appropriate operating system installation tools. Documentation for the upgrade and install should be clear enough that a non-developer can successfully install and test the installation. Install activity should be logged, so that if something does go wrong, it can be figured out later.

Even if they met all the requirement to bill as emergency band-aid application, you still feel it's fraudulent? You're not a fan of rule-of-law, are you

The intent of the emergency band-aid is to compensate for the difference in cost between the emergency room and a primary care physician's office. Very rarely would a primary care office meet the requirements of being an emergency room... but the descriptions of the procedure may be the same.

I'm actually a big fan of the rule of law. The problem with healthcare billing is that is too easy for care providers to deceive the payer.

An increase of 85% just scratches the surface.