In any case, you would need Amazon to actually enforce it.
While they do have more money for legal fees, they would risk a big PR issue if they tried to prevent some guy from working at Walmart after quitting Amazon. Also, the first guy with such a problem wouldn't have a lot of trouble finding someone to help them with legal fees, if only for the publicity.
This is probably just a scare tactic, to discourage people from leaving them, it is unethical, but not really enforceable.
Does that manual encourage bad code ?
For newly written code, things like readability, testability, and maintainability all can come in to whether it is "good" or not
For legacy stuff, Good code is code that works. Who cares how easy it is to read or test as long as it works?
The second one should also include "immutable". If it's hard to understand it will evolve easily to non working, and time spent on improvements can start to creep up very fast.
I have worked in very clever, solid code, but not easy to read. It was then maintained and extended by average, but competent programmers down the road, and turned into a big mess, only because it was so hard to understand.
In my experience, good code is easy to read, above all. That will make it easy to extend it coherently, find bugs and stuff. Also, if it doesn't work OK, it's easy to find out why. The single metric that saves time, money, and improves quality down the road is readability. Eveything else should be suject to that.
And, about the last point in the "article", "efficient", it's nonsense. Premature optimization is the root of all evil. You should _always_ follow the second rule of optimization (see http://c2.com/cgi/wiki?RulesOfOptimization ).
PHP can be good or bad, like any other code. Lately it's getting better.
As an example, do you think this looks bad? Looks pretty good to me.
https://github.com/symfony/sym...
I have some awful, unreadable examples I could share in Java, PHP, Javascript and even C, but chosen language no longer forces you to write bad code. Maybe Perl, but I haven't seen it lately.
An AC, very close to first post, and it is actually spot on!
Unless you can get management to sign on to a mentality of "it will be done when it's right" rather than "it will be done on Thursday" you have no hope of achieving FLOSS levels of success. I'm not saying you shouldn't try your best, merely that you should be aware of your limitations and from whence they come up front.
"OS" mentality is that it will be done when it's _done_. Not when it's _right_.
And it's tautologically true. You don't need management to change their mentality, only to _accept_ reality, and act accordingly. I know it might be too much to ask for, but it's not too much to ask.
While it does make sense to have a roadmap, release dates for new software are too often wrong. It's a good thing to keep yourself honest about expectations, and drive the development process, so you can get quality stuff, in reasonable timeframes, providing the greatest possible value.
Unrealistic expectations and pressure on estimates won't help you get there faster, or better. Being realistic will help your team improve estimations, and also help you complete stuff faster, and better.
You are right in your assessment, but there should be a solution for that.
Time and materials contracts can take care of the issues you are talking about. You can reject a pull request, but still pay for the hours.
It's a lot cheaper to pay for the hours than to fight over them. If it's an employee, help them get better, refine your specs, or maybe move them or replace them, if they are not fit for _that_ project. If it's a contractor, change contractors if they are bad.
If you are contracting software development, it's always better to assume some risks yourself, because that keeps your providers focused on helping you reach your objective, and not contract stuff. If you don't want to take risks, you shouldn't be developing software in the first place, but buying ready-made solutions.
.
I don't know whether what he says is true, but beggars are not a typical sight in communism.
In a communist state, they would either not get much gain by begging on their streets (think Cuba, at least when foreigners are not involved), and or be thrown in jail by doing it (like what they say happens in North Korea)
Also, political leaders enjoying luxury goods and meals is the norm in most countries, communist ("real" or not) or otherwise.
It's not that common for companies to have principles to begin with, tough.
The optimum committee has no members. -- Norman Augustine