372 karma · joined December 7, 2014
Oh so they only want to know about the bad people? That's a relief.
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.
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.
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.
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.
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.
RISC is resoundingly a Yes.
The "VW diesel-gate" aside, I do share your feelings about the quality of CS programs in general. There is nowhere near enough education about real-time systems, high-reliability systems, and formal verification methods. All of these topics are completely appropriate academic material, in addition to being fundamentally useful for business needs. I'm not sure any of these topics are covered in the usual undergraduate curriculum.
Your criticism of Python being dynamically typed is also misguided. There are many benefits of having a dynamically typed language, which I won't bother to enumerate here since this subject gets beaten to death regularly on HN. It is a good choice to make this design decision up front and honor it as the language grows. Guido is not a moron; he knew there would be performance implications. Nobody today chooses Python for it's native performance anyways (although Cython and PyPi have made great strides for common cases).
The value of Python is not in performance, it's in the language simplicity, large ecosystem, and highly developed libraries. There are some disciplines such as machine learning and quantitative finance which are all but predicated upon Python, with excellent results. Comparisons to Go and JS are incongruous; those languages have other benefits which would make them good choices if things like concurrency (Go) and very high level abstractions (JS) are important.
The Python 3 transition was indeed rough, but in no way is it a "debacle". The community is not in "disarray"; that's absurd. The transition to 3 will happen eventually, and indeed this lethargy was caused by deliberate breakage in language features. Maybe not the best decision in hindsight, but far from this cataclysmic fantasy you seem to be depicting.
It is impossible on a practical basis to secure any significant amount of cryptocurrency. Even the most secure known methods of storage have been compromised [1], and computer security has reached a state which means everything is hackable. Every Bitcoin exchange I can think of has lost some significant amount of coins to hacks. I see no reasonable solution for this problem.
[1] http://leaprate.com/2015/02/is-bitcoin-safe-yet-bter-exchang...
EDIT: I have always liked your posts on bitcointalk.org
The big problem that Balaji is completely ignoring is that SHA256 cores implemented in silicon have extraordinarily high power consumption relative to their size (mm2). This is due to the incredibly high signal switch rate inherent to implementing avalanche-style ciphers [1] in hardware. Perversely, most modern semiconductor processes optimize for static (leakage) power, since modern silicon designs are more vulnerable to this than to dynamic power. No rational semiconductor maker will want to include this IP on chip, because it will drastically complicate the power distribution metal layers. Additionally, it will require more expensive packaging, since you will need many more power and ground pins to source/sink the required current. I know this first hand after building a mining ASIC myself. I would venture a guess that most SoC chips would cost significantly more due to the extra engineering time and packaging cost needed to include this IP.
This entire concept is a non-starter for me.
[1] http://research.neustar.biz/2012/02/02/choosing-a-good-hash-...
1. The Throttle Angle function in the Toyota code had a McCabe Cyclomatic Complexity of 146 (over 50 is considered untestable according to slides) [slide 38]
2. The main throttle function was 1300 lines long, and had no directed tests. [slide 38]
3. I find the static analysis results quite alarming. [slide 37]
4. 80+% of variables were declared as global. [slide 40]
I find this to be a stunning lapse of quality, especially for a safety-critical system.
> I've also been privileged to work with HR people for whom the adage "never trust them" was completely false.
I'm glad you had a good experience with HR. Being able to be friends with an HR employee does not invalidate the axiom that you should not trust an HR rep in matters of your career (happiness). There is too large a body of negative examples out there in order to safely ignore it. Everyone can of course can and will make their own choices, but I stand by my previous statements.
A good manager will keep an employee engaged, challenged, and happy. In fact managers can achieve this even if the company itself is not engaged, challenging, and a happy place. Good managers can also shield employees from an array of terrible dysfunction at the company level. All good managers I've ever had have this skill. A bad manager will not only expose company dysfunction, but magnify it, making the employee's job more difficult than if the employee has no manager at all. I've had the latter several times, and it's soul-draining.
The rest of the article reads like a novice's take on the SF startup scene, which I happen to loathe anyways. One funny example is the #7 HR comment, which exposes a pretty big misunderstanding about HR. HR serves no useful purpose to the employee; it exists to shield the company from problems, nothing more. Improving HR will have no meaningful impact on employee retention.
<Edited for tone.>
I don't live in the Palo Alto area and SF itself, because the cost of living is incredibly high. They are nice places for sure, and the social scenes there are more developed. You will have to pay to play there though.
Housing is very expensive, rents are very expensive. I see it as a tax on job portability. The important upside is that SV is the center of the universe for interesting computer science work. I have lived in several other places, and if you want to prioritize your career, and I am certain SV is the place to do it.
I am what is probably now considered "old-skool" (e.g. C++, semiconductors). There are still many opportunities in this space. Mail email me at ynka8+z1i2opfxuvoo@sharklasers.com if you are interested in talking about a job opportunity; the startup I work for is hiring.
I don't like the typical SV startup culture, I find it pretentious and too youthful. The HBO series Silicon Valley is more accurate I think than the general public realizes. That's a bit ironic since I work for a startup right now. :P I find that older engineers make much better decisions, and I'm pleased to be able to work with late-career heavy-hitters in my current company. It makes for a much more stable work environment, and our biz-dev prospects are more realistic than the social media rocket-ship blastoff overnight model.