ath0

Shareholders are allowed to propose items that will appear on the ballot for annual vote, "(1) In order to be eligible to submit a proposal, you must have continuously held at least $2,000 in market value, or 1%, of the company's securities entitled to be voted on the proposal at the meeting for at least one year by the date you submit the proposal." https://www.law.cornell.edu/cfr/text/17/240.14a-8

Before shareholders vote on the proposal, the board of directors can make a recommendation - is this a good idea or a bad idea? In this case, they say: bad idea.

Shareholders aren't bound to agree with the board, but usually do - after all, they're the same folks who nominated the board in the first place.

Love this article but think the headline actually makes the wrong point - this is a product management issue, not a "it may never happen" issue. That it takes someone like James to know two wildly different domains - both the business-level details at risk (a $1M generator is worth potentially damaging if the alternative is a guaranteed $100M revenue loss) and the details of power engineering (overriding the switch only risks the generator, not a datacenter fire or loss of life) - is a shame.

Could the power engineering team have made this tradeoff more clear to the project managers doing the initial install? And yet, exposing a million little configuration options to the end-user isn't the right approach either.

Those are shorter forms of pieces in her long-form book:

https://www.amazon.com/Soul-Octopus-Surprising-Exploration-C...

Quick read, and also recommended for more good octopus anecdotes that inform this question.

TrailOfBits' Algo: https://github.com/trailofbits/algo

Also on EC2, Google and Azure. Also not OpenVPN (native IPSec).

This strikes me as burying the lede -- if TMobile is traffic shaping based on what looks like the speedtest folder, are they also QoS-prioritizing that traffic to get better speedtest results?

Can you spot the mistaken assumption?

It's right here: "Data doesn’t need to go to the headphones, nor do the headphones need to send data back. Digital-to-analog conversion has to be done eventually, because speakers don’t produce sound waves with 1s and 0s."

True for speakers, but headphones are often more than dumb speakers at this point. They're active noise cancelling devices. They're a component of immersive video (why do people buy 5.1 surround systems when they could just wear headphones?).

Or even if you have the standard earphones from the box: do you ever pause the sound, skip a track, or answer a call using the buttons on the cable? If so, you're sending data back to the phone. Surprise!

What other forms of interactivity could we open up if we broke the "one-way, stereo audio only" assumption explicitly?

Don't get me wrong - my preferred earphone vendor doesn't even have Bluetooth support yet and I don't really want to buy another pair of custom Etymotics. But despite that, I recognize there are real experience-driven reasons to do this.

The golf example (from later in the article) is telling: if those most looked-up-to in the profession publicly and exhaustively exhibit a dedication to fair play, and it's part of the culture down to the lowest levels, then it can work much of the time. You also have to be brutal in enforcement: golf pros who sign an incorrect card, even if they just misunderstood a local rule, are disqualified (though this is changing, see http://espn.go.com/golf/story/_/id/13975820/rules-golf-elimi...).

It's true that once people start getting away with cheating, even minor cheating, and others see it, it quickly becomes universal. Like cycling (also from later in the article).

I feel the complete opposite about this -- it's a really good example of management not just making a conceptual decision but diving into the details and making a call, but with respect for all involved. Note that: * The chairperson joins in and speaks with authority. This isn't a VP of eng making a call about two repos. * It's not a binary decision - "cancel development, fire the people affected, leave the product to wither on the vine" - but a nuanced one: don't make decisions that make Firefox worse, I don't pretend to have all the details but will give you an example of one decision that I have an opinion on and who you should look to for advice (the platform and infrastructure teams) * Recognizes that it's not just a technical call but has legal and community issues, and tells you who will be sorting those out as well.

Management is hard -- you can't just make a blunt statement and expect people to fall in line, especially in open-source projects. Would you have preferred a harder line? Do you think that would've been better for the community in the long run?

Which makes sense, sure. But equally consider: did you miss out on opportunities to learn more, quickly from your employer by not being direct about where you disagreed and trying to understand whether she was wrong or you were?

As 'kimscott is trying to point out in thread -- there are ways of being candid that aren't simply "you're wrong and I'm right, so shut up and listen" -- which is not how you should behave, either with your boss or with your subordinates. All things being equal, candor (with empathy toward the recipient and openness to being wrong) leads to better results than keeping your opinions to yourself and stewing silently.

Posting to +1 only because of my username for the last 25 years. Godspeed.

Washington Post, Gawker, and others who use the SecureDrop software for soliciting leaks are a great use case for .onion+EV. You get the assurance that your connection is encrypted and, as much as possible, anonymous from the person you're connecting to; you get the assertion of the person you're leaking to that they are who they claim to be; and you get a 3rd-party validating with high confidence that someone authorized to represent that company set up the domain you're leaking to.

And maybe also not written by someone named "Tyler Durden"?

Good article and timely, because they just did another big response two days ago: http://blogs.technet.com/b/mmpc/archive/2014/10/14/msrt-octo...

While this didn't involve a broad takedown of a public provider (as far as I'm aware), it did involve coordinated release of tools and more-targeted takedown requests through their semi-private "Coordinated Malware Eradication" program. On balance, I think what Microsoft is doing is a good thing, but public scrutiny and discussion of any organization/cartel that operates in secret is equally important.

Did you ever get it to recognize the snowman? That's my go-to also. I've tried two snowballs, three snowballs, with and without arms, with and without stars, with and without hat... and all I keep getting is tongue. I am pretty bad at drawing though.

There are certain cultural imperatives; catchphrases that get repeated. Like Facebook's "move fast and break things." That's an interesting statement in and of itself, but what's more interesting is watching how people interpret that imperative and get things done.

Don't want to go into too many examples, but let's take the "we maintain an incredibly high hiring bar, because good people want to work with good people." Everyone says that; how do you actually execute on that in practice? What interview practices work? One well-known public thing you can see from reading Glassdoor interviews is that the founders try to interview every candidate. One of the most memorable things about my time there is that even the guy who was hired to stock the kitchen went through an intense interview process; which seems like overkill until you meet him and realize the depth of pride, customer service and creativity he brings to his job is every bit as strong as the engineers we hire. Not everyone who says "we maintain a high hiring bar" would go through that kind of effort.

(P.S. re: the above "lifelong friends" comment as well - that guy, who I am still friends with, continues to post photos of particularly well-executed Palantir meals to private social media. So while I respect the feeling that 'it sounds like the military' -- like the military, I'd say it's hard work in the short term, occasionally nonsensical, but for people who are willing to do it it's very much a long-term positive experience.)

Worked for Palantir from 2010-2012. Palantir will push you hard (if you let it, and are interested in doing so); it's the highest-performing team I've ever worked with, and I learned a ton both technically and culturally (how to interview, how to hire, how to productively have high expectations of your colleagues) that has served me well in the other roles -- even though it wasn't immediately obvious what I was learning when I was there.

That said, there's a lot that's rough about the place, especially as it's gotten larger. You'll likely have a little more freedom than at Facebook, but I wouldn't expect to have a significant impact on the product -- though you will absolutely see an impact on a smaller number of enterprise customers. The culture can be a little overwhelming; it's hard to get oriented as a new person. You need to take responsibility for learning things for yourself and have to think on your feet -- don't expect your colleagues to spend a lot of time training you.

Because while that's the top-line for the 18,000 people affected (12,500 today), he'd desperately like that not to be the only thing the other 100,000 people who are staying hear. He wants the rest of the people to first hear: "We're changing for the better, and while these layoffs are a bad thing, it's necessary pain we have to go through to be better in the long run." That means wrapping the bad news with as much context and transparency as you can, every time you talk about it.

I know I'm being trolled, but sure, I'll jump in.

My high school held me to high standards and introduced me to broad influences - beyond technology - that help me see problems in a new light. Technically, I had access to a modern computer lab that let me try new things; when I found security holes, I didn't get kicked out but was tasked with fixing them.

In undergrad, I took a program that taught every new computer science class in a different language - without teaching you the language; assuming you'd have to pick it up in order to learn the underlying concepts. That kept me on my toes, helped remind me that I wasn't an expert in everything, and made me much more agile in keeping up with the languages and technology that have come out since undergrad. (I graduated in 2001... so almost none of the languages I do my daily work in existed then.)

In grad school, I expected to go in to study security but was exposed to infovis by joining a program known for it -- meaning I got to interact with people who knew the field forward and backward, giving me skills quickly, something to strive for, and a peek into the future of the field. This took my career in a different, and, I think, more exciting direction.

So what great schooling enough? Of course not. I worked my tail off, took a variety of good and less good jobs, and tended to relationships outside of school that helped me find other ways to learn and to do. And we'll never know the counterfactual. But I can point to a bunch of specific ways where good schooling put me on a successful path, and I'm honestly surprised that the sentiment here is so negative.

April Fools Day RFC's are a grand tradition. My favorite is "The Extension of MIME Content Types to a New Medium", RFC 1437... complete with extremely dated Dan Quayle joke. IP over Avian Carriers, RFC 2549, is a close second.

It's this line -- "given a spec, can reliably estimate the time to execute that spec" -- that, I would guess, separates the types of jobs I've experienced from yours. I've never been given a spec that was worth the wiki page it was written on. In most of the jobs I've experienced, "effectiveness" (get done what you're given) and "competence" (don't cause extra work for others) are barely a minimum bar to success; to be successful, colleagues also need "insight" (look past the documented requirement to the reasons behind it) and "creativity" (design a solution that solves the documented problem and three related undocumented ones).

You're right, "passion" isn't one of the things to hire for. At best, in my experience, it's highly correlated with the breadth of experience that fuels "creativity" and "effectiveness" - at least, in the sense that it causes people to be persistent against hard and unclear problems. It's fair to ask whether this should be required for teammates or just co-founders -- but even in my most enterprise-y gigs, I've rarely seen a team that could succeed without people with passion helping drive the work.

People are motivated by different things. "Below market" only matters if you judge yourself by how much you're paid compared to your peers. "Having no work-life balance" assumes that your "life" doesn't benefit from "work" in ways other than the size of your paycheck.

If you already have a house/apartment you like and will still be able to afford with this job, find the work you're doing interesting, have the appreciation of your co-workers and the freedom to do your work the way you want (because no one else who works there is an IT person); if you find playing video games with colleagues a reasonable facsimile of "life"; if being a visible member of a team that has a youtube channel with 10s of thousands of subscribers who look up to them is more important than owning a bigger TV; then this job may be worthwhile for you.

And why is it a problem that someone would rather have those things than a salary at market rates, or an ability to go home at 5pm and spend time with their family not thinking about work?

Speaking for myself on the specific points you've raised: We're a django shop, but being a rails dev doesn't rule anyone out. A demonstrated record of shipping product and solving hard problems, regardless of language, is generally better than a lot of buzzwords that happen to be on point with the tech I'm working with to day. That candidate will probably get a phone screen, at least. A list of job responsibilities or technologies on a resume won't get you an interview if that tech isn't a good match for what I care about today.

But that's rails... ruby is a pretty strong language, and it's a much closer map to python than other options. As for your other languages...

Someone who's spent their life in PHP with no experience outside that language? At this point, I'd probably pass on that resume. The problems I deal with require a breadth of experience in deeper software engineering-y topics: networking, storage, maintainability... my assumption would be that you haven't been given hard enough problems that require you to get outside of the PHP box, if that's all you've ever done.

Similarly Java vs. Scala. I see a lots of J2EE resumes, and my experience with interviewing those folks is they may understand the J2EE/Hibernate/SOA/webapp stack, but when it comes to non-webapp problems, they're lost. I'd be more likely to talk to someone who has Java, C and Python experience, but no Scala, than someone who's got a broad Java base but has never branched out of that particular language. Scala experience, whether or not immediately relevant, is more likely to be correlated to be harder problems, self-development and exploration -- at the very least, that someone is trying to keep up with industry trends.

Maybe my J2EE and PHP judgments aren't fair; but they're heuristics developed over some time.

Jon Rosenberg (of goats.com)'s experiment with this in the early 2000s -- not bitcoin, which didn't exist yet, but micropayments in general -- was the first one I saw with hard numbers about why this will be extremely difficult. Sadly, he's taken his site offline, but short version: There's a huge difference in someone's mind between "free", and "not free"; it's seen as a change in category, not in degree. Having to commit any amount of money - even $1 - significantly reduces your audience, but once someone's gotten over the hump of willing to pay, you might as well ask them to make a larger purchase of a T-Shirt or subscription.

This sort of experiment has been repeated many times. Folks like Flattr have tried to tie this to social networks, so it's seamless; and the NYTimes model of metered paywalls (smaller publishers can use something like http://www.tinypass.com/, which Andrew Sullivan's blog uses) seems to be taking over magazine publishing. Even attempts to turn cable subscriptions a la carte aren't doing well, as Megan McArdle explains: http://www.theatlantic.com/business/archive/2011/06/why-cant...

I get why the Genesis Block would have enthusiasm for this idea. But one-pass micropayments, Bitcoin or otherwise, don't seem like the future to me.

The hard part of the job isn't writing code to a detailed spec that's assigned to you. It's knowing how to ask for clarification on requirements; how to balance speed of delivery with nebulous ideas of quality (how readable is my code, how effective are my tests, how extensible); how to decide which tools are right for the job.

When I look for cultural fit, I mean: will you have productive conversations with your colleagues; have you shown yourself to be inquisitive about new things beyond what you're assigned so that you have a good understanding of what a solved problem looks like; will you force yourself to find a way around hard problems or will you quietly give up and call the problem impossible or blame someone else; are you interested in solving customer problems and iterating rapidly, or in building the most "well-engineered" solution; do you think your role in the organization is to build products or direct them.

These aren't easy questions to answer, and they do open themselves up to bias in how you evaluate candidates. I like asking about folks' CV - even though there's already a written summary - to see what parts of a problem you considered most exciting and hard; I think that's revealing. But may not work for everyone.

Don't forget to browse the photo gallery: http://www.flickr.com/groups/cloud-to-butt/

And the code on github: https://github.com/panicsteve/cloud-to-butt

Under the U.S. sentencing guidelines (e.g. http://www.ussc.gov/Guidelines/2011_Guidelines/Manual_HTML/5... or state equivalents), this is already the case. Although you may be sentenced to "105 years" for multiple crimes, if they're related to the same activity, those sentences are usually served "concurrently." It's left to the judge's discretion.

Your complaint at this point should be with prosecutors that use the most draconian possible sentence to promote themselves and pressure defendants, and with a media that loves the shock value of numbers like "105 years" when such a sentence would almost certainly never happen.