And I wouldn't say standard of excellence--just the possibility of excellence. With closed source you can't have even that. You pretty much have to assume the worst.
I suspect they do a good job at a technical level, but they have interests in advertising that are at odds with my privacy interests. I also have no way to know if they are doing Dark Nefarious Things.
From your initial comment, I got the impression that you were claiming that closed source software could not be excellent..meaning secure.
By the way, I'm a big GPL/free software nut. However, I understand the place of closed source software, and under the right circumstances, it can indeed be excellent.
This is where I've come around to appreciating the FSF's moral argument for Free software a bit more than the instrumental-utility argument of the Open Source movement.
Open Source can be bad, in terms of quality. Closed source can be good, in terms of quality.
Security is an interesting case where I don't believe that you can be trustworthy and closed. Could the code be good? Yes. Can I validate in any meaningful sense that it doesn't violate my expectations? No.
Of course it's possible to have obfuscated malicious behavior in Free/Open Source software. But, there is at least the possibility of descovery of such defects. With closed source, there isn't.
We'll have to diverge a little, then, but not too much.
In some cases, such as the security sensitive code written at Google, there are far more eyes on the code than there are with all too much of the critical, security sensitive open source code.
In my mind, it's a matter of alignment of interests.
For the cases of 'run of the mill' security questions, such as buffer overflows, password leaks and the like, Google, Facebook and I have fully aligned interests. None of us want those things in anybody's code.
Things get harder for other security questions, such as data collection, and cooperation with surveillance, legal and otherwise.
In the latter case, state surveillance, Google (and other like entities) have interests that are mostly aligned with mine, but not entirely. They're pushing back on warrant-less, Patriot Act type crap, while efficiently complying with traditional directed warrant disclosures. (As far as we know!)
Fully open source and free software will almost always have full alignment with my interests, and so is better in that regard.
As far as code-level bugs, I think the general rule is that closed source code is pretty poor at companies, with a few notable exceptions, where I think things are a heck of a lot better.
Finally: Wow, I just reminded myself that this thread talking about a new Amazon product. Crazy. (:
So you're an IC suffering under "incompetent management". Yeah sometimes you just can't work around this, but often times you can learn to sell your ideas better to those specific people. Maybe they don't jive with your delivery. Change it.
If you speak the language of revenue, you can rationalize almost anything that will grow it responsibly.
If the language of revenue and various delivery tactics still don't convince your management, then it's time to leave.
I too struggle with focusing on the negative sometimes, so I constantly encourage myself (and the author and others who are feeling similarly) to redouble efforts to optimistically communicate in the language of revenue.
Idiot: We don't want to make any bad hires! Therefore, we reject a lot of good candidates!
FSK: If you pass on many good candidates, and you have a small chance of hiring any given bad candidate, then each good candidate you reject actually INCREASES your odds of making a bad hire.
Idiot: We made a bad hire once! Never again! Now we reject lots of good candidates to avoid that repeat disaster!
FSK: But, if you want to minimize your bad hire rate, you also have to minimize the number of good candidates you reject.
Idiot: NO! NO! NO! The way you make sure you hire no bad candidates is to be so strict that you reject lots of good ones! That's what everyone told me so it must be right!
In one ear and out the other. Why do people who don't understand statistics get to be managers? If you don't understand this statistics argument I made, you're unqualified to work in any sort of technical area.
It's actually fairly reasonable. The manager doesn't want to avoid hiring bad candidates. The manager wants to avoid being blamed for hiring bad candidates. They want to be able to say "I looked really really hard for reasons why Bob was a bad hire, and didn't find any, so you can't blame me for Bob being a bad hire."
Whether or not this actually reduces the number of bad hires is beside the point. It's a classic principle-agent problem.
You're missing something vital here. They're not rejecting good candidates because they're good candidates, they're rejecting them because they're not sure enough that they're good candidates.
They fear they might be bad candidates. They'd rather reject too many than too few, so they make sure they reject everybody who they're not 100% is a good candidate. That means they may reject some good candidates that aren't easily identified as such, but it doesn't increase their chance of hiring a bad candidate; it decreases it.
Strictly speaking, I think raising the standards also could lower the probability of a bad hire (depends on the model - is bad hire completely random? does it depend on some parameter that is controlled?) together with a probability of a good hire, so I'm not sure it is a robust argument that raising standards always raises chance of a bad hire. I'd be happy to see a more rigorous proof (I know it's complete waste of time but for some people it's fun).
Basing all of your management decisions purely on statistics is a bad strategy. You're assuming that the weighting of good vs. bad candidate is the same, when they're not.
Hiring a good employee is not nearly as impactful as hiring a bad one. If you can have a strategy that filters out 100% of bad employees, but unfortunately also filters out 90% of good employees, this is preferable to filtering only 50% of good employees, but also only filtering 90% of bad employees. You may have more good employees with the latter strategy, but the bad employees can kill the team.
People have an irrational belief in their ability to tell the difference. This is how one gets such flawed thinking in the first place (regarding priors and probability distributions).
Firms are hierarchy-based entities. "Technical Merit" is about a third or fourth order away from what really drives the hiring decision. Its also very imperfect predictor of actual performance.
The issues is that companies use the term all the time. They want people to believe they were hired for their merit, but merit is almost always 'fit' and not technical in nature. The technical hoops are just a CYA for when the 'fit' doesn't work out (mis-judgement) and they need something to point to as to that is not arbitrary in nature to explain how other people were not hired instead.
"Apple is supplying this information to help you plan for the adoption of the technologies and programming interfaces described herein for use on Apple-branded products. "
Honestly, in this day and age the fact that you have an engineering degree is a sign that you can get your ass off the couch and strive to become something... not really any sign that you have something cooking in your head. Although, if you get through any engineering major curriculum you're likely not an complete idiot.
Engineering is a discipline. It's systematic, rigid, concise and if you fuck up you're liable for your actions. Would you hire someone who claims to be a self-taught electrical engineer, mechanical engineer? No. You know why? Because these people work their asses off to become licensed. Your hiring manager will probably lose people on his team if he hires someone who doesn't even have a single college credit. It's a matter of discipline and respect for your colleagues. In some areas it's regulated and you cannot hire an engineer without a degree.
Would you hire a self-taught software engineer? You can. What's the end result? All too often, your company on front-page news because this person made a rookie security mistake. Is he or she going to be responsible for leaking thousands of sensitive records to public? No. They might get fired, but that's it. Take this same example to medical field where a software bug can kill (and has before i.e. radiation treatments) and all of a sudden you can't even prosecute this "engineer" for murder.
In many countries "Engineer" is a protected title, and can only be used by someone who holds a Bachelor of Engineering or better. The difference between a BEng and BSc at my University basically amounted to more stringent record keeping and auditing standards for the University, and slightly more expensive tuition because of that.
I'm not saying I agree or disagree with GP, but some engineering disciplines require that you be licensed and are then called a "P.E.", Professional Engineer. Computer programmers don't, of course, and there are some that think we should be.
Actually, DeveloperAuction is moving into other cities soon enough. After speaking with the team a bit, I got the impression that they see Silicon Valley as the testbed so they can perfect the process before taking it more universal.
I'm not really sure why this is so hard to see, the auction model is so weird, of course it'll take some time to figure out the kinks before "going global".
Bring better ideas to the table on how to achieve them using your understanding of what is the ideal mix of easy/hard and long-term/short-term.
Track your efforts against the bottom line financials. Earn the raise you seek.