What you just described is, put simply, to follow engineering principles. Some people would argue that Software Development is not an engineering discipline but a craftsmanship.
And anyways, it would still be a huge scandal if the FAA allowed someone, (or a team of someones) without a degree in CS, to check an airplaine's software. Does this need to be regulated as a law, and thus, recognition of the Software Development discipline as a profession ?
Altough I agree with you, I still definitely think we are heading towards a future where in order for your code to ship, you will need to be a certified programmer, or have it validated by a certified programmer, at least in some industries.
Do you think it is safe, for say, a non certified (read: a guy with no CS degree) programmer to design and code software that runs on an MRI machine ? Or the one which controls airplaines ?
If airplaines start crashing because of a software fault, do you think we could and should blame the programmer for not having made the required tests ?
Software _development_ is a very young discipline, and as such has not yet been regulated. But I believe the day will come where it will.
Had a try and it seems promising. The only drawback I see is that there are still bugs, and the owner is the sole developer for the project, and he seem to have plenty of other projects going on...
So basically, it is a triple-store with keeps track of time and no mutation of past.
They have their own query language but it looks to me that they did a great job at making it as close to SPARQL as possible, which personally I am familiar with.
I often find myself using 1 << Y when I mean 2^Y, but just because it is faster to write and generally accepted in all languages than to find pow in the current language I am writing in...
I discovered this when I was debugging a Netbeans generated REST Webservices. The web UI makes clever use of OPTIONS in order to list the available services and their parameters automatically :).
I very often hear this comment from my fellow developper colleagues.
In our startup, I am responsible for the frontend coding. Very frequently, I get requests from other developpers to implement this or this, and very often those requests are annotated by a "c'mon, it is just CSS, it'll only take you 5 minutes" when they have absolutely no idea what they are talking about, because they never ever did real frontend developpment. They simply think that everything boils down to HTML and that frontend is NOT really programming. Attempting to explain that a frontend also has logic similar to backend, and that no, plotting graphs when you don't even have the data modeled is not just a 2 liner with Google Visualisation.
I am always offended by people estimating time for work they never did. So I find myself very rarely giving estimations. Sometimes when I have a very precise idea on how to implement an idea right when I'm being told about it, I usually say "yeah this is definitely doable in a short time span". Meaning things that do not take more than half a day to implement, because you already compiled the code in your brain.
Now, when a colleague of mine estimates stuff for me, I tell them "No I don't think this is going to take X minutes to implement. If you think it is implementable so fast, why don't you go ahead and do it.". When they take it to the word, and I see them still struggling after many hours on some problem that are trivial to me, I will go ahead and help them out. After a few times, they usually won't bother me with estimations anymore... NOT.
Even if you don't store that information, and even if it is not really useful, you should maybe note somewhere that all the "leak" information is sent to Plumbr servers.
Codex is abysmal for UI design imo.