HN user
“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.
Hoare's CSP is exactly this. It's not a programming language per se, but I know of several DSL's that were built using CSP syntax. https://en.wikipedia.org/wiki/Communicating_sequential_proce...
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.
The claim about RISC being a No is bizarre. RISC has definitely won, for 2 big reasons: 1. Intel redesigned their x86 processors to execute using a RISC model internally. AMD is using the same idea. A processor architecture is defined by its execution model (not it's external encoding). 2. ARM is more ubiquitous than Intel, and ARM is a RISC architecture. In fact, ARM may be the dominant processor architecture in the next 10 years.
RISC is resoundingly a Yes.
I find your comment about CS programs a bit misplaced. Are you aware that a research team from WVU actually uncovered this emissions problem in the first place?
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.
This would be a good time to point out that a similar auto software story found its way to HN recently: https://news.ycombinator.com/item?id=9643204 Once Toyota's ECU code was reviewed by domain experts, they found extraordinary lapses in basic software quality practices. This and the VW fiasco clearly show that hiding ECU code is the wrong way to go. We can directly measure the negative consequences, and these are only 2 such incidents discovered recently. Who knows how many more issues are still hiding. We won't really know how at risk we are unless there is some kind of 3rd party review process, required by law. Clearly, the auto industry will prioritize profits and liability over actual quality, in much the same way that banks will never voluntarily limit their risk at the sacrifice of profits. Self-regulation is not working.
Your comment is grossly overstating the issue, and unnecessarily inflammatory. I have reviewed the type hints syntax, and it's not so bad. It's doubtful that anything nicer can be implemented on top of what you have clearly pointed out is a dynamically typed language.
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.
Rumor has it that Altera was unhappy with Intel's process and was going to bail. Intel was so dependent on their cooperation that acquisition started to look good.
You should expect this trend to continue. Semiconductors have become a hideously expensive business, aggravated by fewer fabs and more draconian fab/IP acquisition costs. It's a well known that nobody on Sand Hill road will touch semiconductor startups at all, leading to a stagnant collection of semiconductor companies founded 20+ years ago. There was recently announced a semi-only incubator here in SV[1] because nobody can raise any traditional VC money, although time will tell how many successful exits it will have.
You forgot the most damaging one: - security
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
Yes, they are a legitimate company. They showed up on the Bitcoin radar back in Nov 2013 [1]. They started as a private mining consortium with their own chip design, and now presumably they want to pivot into a consumer-facing business.
I am extremely glad that most comments here see the inherent craziness of this idea. I am a hardware designer who participated heavily in mining since Jan 2011, and gave up completely on Bitcoin in summer of 2014.
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-...
FPGAs may have opened up options for prototyping, yes. However they have done nothing whatsoever for production. It's economically infeasible to productize and FPGA based product since the only ones worth using are all ~$10k per unit, with price breaks only available to 1M unit quantities. It is also almost entirely impossible to commercialize any design with an ASIC, since it takes a minimum of $10-20M to design it (and pay the foundry). Semiconductor startups have been dying a slow death since the 90s, and will continue to disappear completely from the landscape, suffering a "death by NRE."
This is an absolutely fascinating slide set. Thanks submitter very much for the link. I have written embedded C before, and the following facts just blow my mind:
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.
You make a good point. There are some kinds of "institutional dysfunction" that are too problematic to overcome. It that sense it's really not only about the manager. At best managers can carve out a small pocket of good work environment for the employee, but even that has limits that won't be enough for people to stay.
If by "projecting", you mean drawing on my experience, then of course I am.
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.
It sounded good until I got to #2. This is utterly false. I would go so far as to say canonically-untrue: the only reason any employee leaves is because of their boss.
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.>
Longtime lurker, never posted on HN before. I am a mid-career software engineer working for a hardware company.
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.