silverpikezero

> “We’re not interested in the millions of devices of everyday citizens,” he [Comey] said in New York at Fordham University’s International Conference on Cyber Security. “We’re interested in those devices that have been used to plan or execute terrorist or criminal activities.”

Oh so they only want to know about the bad people? That's a relief.

I experienced the exact same feelings as you. Until I started interviewing candidates in quantity, I had no clue how many candidates cannot complete FizzBuzz. The reported failure rates of this simple test are completely legitimate. In my own interviewing, it comes out at about 50/50. The 50% who do pass often make some significant conceptual mistake, for which I'm generally pretty forgiving since interviews can be a stressful experience. This question comes at the end of a hiring pipeline that does 2 phone screens before the on-site happens.

> Title's probably aren't going to be given without some other political reasoning. They have to be claimed. Same goes for "Director", "Head of", and "VP" titles. Titles are rarely assigned based on merit, so stop trying to earn them.

My god, that's a spot-on piece of wisdom if I've ever heard it. Some titles like Principal and Architect can be earned through hard work and exemplary performance. C-level titles and Director/VP almost never operate on merit.

Tax Loss Harvesting. This is the sole reason why Betterment(/Wealthfront) is superior to Vanguard. The benefits of this technique more than offset any fees they charge.

I'm dismayed to see most of the advice given to you by HN is bad. I am in a very similar situation, and it has been ongoing for years. I have also been bullied for some substantial parts of my life, so I understand the power dynamic very well.

In my recent experience, there is a playbook that you should use. This playbook is designed to be used in a one-on-one setting, between the bully and the person defending herself. I consider it fairly literal; you should memorize this sequence, rehearse it, and play it out as close as possible to how you rehearse. It is also intended to be used without any emotion; the goal is to be as matter-of-fact as humanly possible. It goes like this:

1. Point out a very specific problem behavior (screaming at you, some other event). Be as specific as possible, and use times/dates if you know them. There should be zero ambiguity about this, and the bully should never have leeway to disclaim the event. 2. Explain how it made you feel (angry, demotivated, alienated, etc.) 3. Say "when you did #1, the message I received was (.....) Was that the intended message?". A common example from my own experience is "I feel like I'm perceived as incompetent, and not any value to the team." 4. Regardless of the answer to #3, specifically say the words "In the future, don't do that again." Don't use the words "request" or "would like" in this response. 5. Explain the consequences of breaking directive #4. Something like "If this happens again, I will report the incident to HR (or your manager)."

This recipe has corrected nearly every incident of harassment and bullying I have encountered (well, at least as an adult). It won't fix the underlying issues; someone might still hate your guts, be jealous of you, or use you as a scapegoat. Those are deeper issues that this kind of recipe can't address. Nonetheless, this script directly addresses the problematic behavior, and it opens the door to confronting some deeper problems once the bully realizes that their bullying is visible and unaccepted. Strange as it sounds, most bullies think that their behavior is invisible to all but the victim. Exposing the bully to others can shift the power balance substantially.

The other thing I recommend is to keep a work diary. You don't need to write in it every day (although, in a problem workplace, you may end up with >1 entries a day). In this diary, I encourage you to record events that took place, how you feel about them, and any technical consequences of that event. I have noticed that bullying tends to produce technical changes in team function which hurts the product and hurts the operational efficiency of the group. If these kinds of disputes ever escalate to HR, which sounds very likely in your case, you will need this diary to establish a pattern of behavior and demand resolution. It will become your most valuable tool to improve your situation. It also serves as a somewhat impartial record of what happened. You may decide that, after reviewing X months of work diary, these issues are not that serious, and your emotional reaction is dominating how you feel. In my own case, I expected this to be true (I didn't trust myself enough), but it became obvious after a 1.5-year diary review that the problem wasn't me. :)

Good luck.

I don't know why you are getting downvoted. Clause #2 would require the inclusion of the BSD license with any release of compiled code. This is a very serious issue with the library. Any additional licensing terms which must be propagated to the compiled software is bad juju.

I agree in principle that Jeremy does not deserve any proceeds of the sale, because he did not contribute to any of the valuable IP that GM wants to acquire.

But there is one serious issue here I don't understand (devil's advocate mode) ....

If Kyle and Jeremy actually founded a Delaware C-corp in Sept 2013 (claim #11), then both their names would be on the officer's list. If that charter specifies a 50/50 split of corporate control, then legally Kyle has no ability to simply tell Jeremey that he's "fired" (claim #14). In fact, I don't think it's legal to fire a significant shareholder outright, unless you have an official company meeting and hold a vote. In this case, it's just 2 guys, so theoretically some impromptu meetup counts as a shareholder meeting. Also note here that the courts don't like having shareholder meetings without records, and in such cases leads the courts to treat such activities as non-corporate events (aka unofficial). In any case, it boils down to what ownership was declared when the C-corp was incorporated.

If someone controls the majority voting rights (or a collection of voters), then they can vote to remove someone from the shareholder's group. However, as far as I know you cannot simply seize ownership from the person you remove from the shareholder's group. The company must then be valued, and the person being ousted must be compensated for the value of his share. Furthermore, you can't simply revise arbitrarily future ownership. Jeremy's holdings would be appropriately diluted whenever fundraising events occur. Weirdly, Jeremy expected to receive his "50%", which as any person should know would have been diluted by investment rounds. Major investors are always involved during these events, and everyone knows exactly what they are getting. The fact that he thought at the end he would "get his 50%" leads me to believe he never cared about asserting ownership until the final big payday arrived.

I think Cruise as a company has a serious problem. If the documentation exists to prove this 50/50 ownership in Sept 2013, there is no way this lawsuit will be smooth sailing.

Or, we all stop assuming that people are here to "humblebrag", and contribute different points of view. In addition, maybe we all use terminology that is widely understood by others, since the purpose of HN is technical communication.

Agreed. In computer science, CSP = Tony Hoare's Communicating Sequential Processes. It's one of the foundations of Go's channel based architecture.

It really does explain a lot though. This is why, when down the road Facebook needs to make revenue or suffer the wrath of investors, your personal life will become their cash machine. This is already true; just wait, it can get much worse than it is now.

Not only that, but the Skype UI is totally different on every platform. I run the Windows client at home, the Linux client at work, and my boss runs the iOS client for team meetings. Each one of them has a very different look and feel, and even different context menu options. Such bizarre inconsistencies. There are too many to list them all here, but it's the most chaotic mishmash of user controls I've ever seen on a desktop app.

The big problem I see with this idea is that scrappy, do-whatever-it-takes people almost never write clean code, checkin cleanly, test properly, and practice good product design. I value these things more than "rugged individualism". Furthermore, if your software team is doing sales, that's a really bad allocation of talent. Even the tinyest of startups should have dedicated roles for the other dimensions of your business (e.g. Sales, Support, HR, CTO). You pit 2 teams against one another with the goal of producing a great product, and one team has a wide spectrum of talent, the other has great software engineering discipline, I would bet on the latter team every time.

Startups should realize that this is a thoroughly idiotic notion, and should abandon it ASAP. The one thing that large software companies do well is SHIP PRODUCTS. A good software engineer is someone who can ship a product, even if its ill-defined or not feature-complete. This is a virtue. Small companies, especially startups, have a horrible track record for shipping software that in any way resembles its product plan.

At my startup, candidates from large companies are immediately prioritized in the hiring queue. This strategy has always paid off; there is a high correlation between large company experience and good software engineering practices.

It's not a bogus argument. The author here is flat out incorrect. There are many bit-level resources on a modern FPGA which could be configured to both source and sink current on the same wire. Any transistors set in this mode most certainly will burn out, at minimum the wire track, but at maximum an entire region of the die.

EDIT: Modern process makes this problem worse actually, since wires are by definition smaller, decreasing their failure threshold. Even a short for a nanosecond can cause irreversible damage.