Cisco's CEO internal memo leaked - <AUTHOR> http://blogs.reuters.com/columns/2011/04/05/text-of-chambers-staff-memo/ <comment><USER2> Sounds like typical turgid ceo-speak. Is there anything in there besides generalities about "vision", "strategy", and "market"?

"tough decisions" is usually a codeword for layoffs so I guess this a 2000 word note prompting employees to freshen up their resumes?

<comment><USER3> Yep, that's what the memo screams to me. Get your resumes updated.

And along with that, it seems too "proper" to be a leaked memo. I'm guessing it was "Confidential" but intended to be leaked. Gives it that appeal of secrecy.

</comment></comment><comment><USER4> If it's not seen as rote/generic by those who read it, it's a good memo. If it's seen as "office as usual," it'll work against itself.

This is smart organizational behavior being put into action: while 30 days isn't enough time to meet with most in the company, it shows that the COO is pushing to lead through consensus, and it shows that he's listening to common employee problems.

On Reuters' website, people have been saying that this is a CEO being deceptive; this is not the case. If they think that, either they're too used to corporate communications burning them from this perspective, or they're unused to clear, honest communications. This is a CEO and COO telling employees that there will 1) be change, and 2) it will be mostly a process/managerial change.

By getting employees' assent and respect, it makes eventual-changes easier, and also allows for the regular employees to feel that there is clarity and vision leading them (instead of inexplicable changes that confound both internal employees and external pundits).

<comment><USER5> Cisco's always been honest like that. I don't care too much for their products or strategies but I admire the honesty within the company.

After the bubble popped the company I was in came up with this idiotic new plan: if you want a raise you have to convince the people above you that you deserve it. This meant that if you wanted one (everyone did of course) you could go to your manager and set up some goals to achieve that would get you that raise. The manager would, of course, take what ever concrete goals you suggested and make them more fuzzy. When the yearly review came 'round and it was time to see how you were doing you would find that somehow you had not met your requirements. Morale took a nose dive because none of us were getting raises and it was all our own fault, despite our best efforts.

Then we talked to an employee of Cisco. Cisco had told them straight up, at almost the same time to the day, that times were tough after the bubble popped and that no one in the company would be getting any kind of raise until things turned around. Not the CEO, not the janitor. No one. Then it all finally made sense. I gained a ton of respect for Cisco and lost any remaining respect I might have had for the hell hole I was working at.

</comment></comment><comment><USER6> Cisco has instituted boards and committees for everything in the last few years. Besides layoffs and a re-prioritization, this memo also calls out the lack of speed and accountability that has resulted; I believe this is an indication that those structures are also going to be changed.

</comment><comment><USER7> I should mine this thing for my Android mission statement generator.

[https://market.android.com/details?id=org.thibault.android.b...](https://market.android.com/details?id=org.thibault.android.buzzphrase)

</comment><comment><USER8> Sorry, lost me at "We will accelerate our leadership across our five priorities".

What the heck does that mean exactly?!!</comment>


Eric Ries and Steve Blank discuss minimum viable product - <AUTHOR> http://www.nytimes.com/2010/04/25/business/25unboxed.html?src=busln

<comment><USER2> I find it amusing that people see a "start-up" as a goal.

The article refers to how these gents "...think they have a better way to build a start-up". The goal is to build a _profitable business_. One doesn't seek to build a startup; rather, the start-up phase in any business is hopefully short-lived. It's usually a painful time, full of uncertainty and lots of pressure. When the business succeeds -- yes, _then_ nostalgia for those early days is appropriate and well-placed.

So often, though, folks become enamored of the romanticized image of a Silicon Valley start-up scene. It's a Cargo Cult mentality. Fascinating.

<comment><USER3> The central thesis to Steve's keynote at sllconf was that you've failed if you stay a startup instead of making the transition to a large, profitable company.</comment></comment>


On the Speed of Light, Innovation, and the Future of Parsing - <AUTHOR> http://www.codekana.com/blog/2009/04/02/on-the-speed-of-light-innovation-and-the-future-of-parsing/

<comment><USER2> And here's something I'd like to see in the future: A persistent OS-provided facility for explaining the origin of configuration decisions.

Linux has most configuration in text files, which is already better than binary files, but sometimes you have to do a lot of digging around in documentation to determine what statements of what files determine what configuration options.

In many ways, the links between configuration files are opaque as if they were dynamic (try determining semantic links between disparate config files using standard unix tools), however it's clear that most configuration is in fact mostly static and so it would be great to be able to access this data (like dependencies) easily to aid with automatic dependency management and debugging.

It would be great if in most cases, when the actual configuration differs from what you expect, you could ask the system why and it would tell you all the specific statements of config files that affected the configuration of the particular thing you're asking about (at various levels of granularity and abstraction). You could then easily see what you need to change to have the configuration you want.

</comment><comment><USER3> On the idea that problems which seem solved to some people are far from solved, indeed. Of course.

I suspect, however, that the idea that there has ever been some kind of consensus that all problems in software were solved, or all problems in Physics were solved, is BS. Fun BS because it is always fun to ascribe a single personality to a large group, and then point out the foolish inconsistencies or limitations to what "they" say as though they were a singular personal pronoun.

</comment><comment><USER4> This was a nice read and I learned a thing or two, thanks.

Hopefully progress continues to be made in the area of things like better parsing for more helpful coding environments, because while it feels incredibly "impure", there are times when I almost feel like having language rules (such as "End If", though not as ugly hopefully) solely for the purpose of making my editor more helpful would be a worthwhile tradeoff. Emphasis on "almost", but still.

Just as intelligent programming language design saves time, intelligent syntax highlighting and other editor provided assistance does too (and a non- negligible amount at that).

</comment><comment><USER5> The big new idea that's said to be uncharted territory reminds me of research from the 90s, actually:

"We also exploit the tight integration between versioning and incremental analysis to provide a novel history-sensitive approach to error handling. Our error recovery mechanism reports problems in terms of the user's own changes in a language-independent, non-correcting, automated, and fully incremental manner."

[http://techreports.lib.berkeley.edu/accessPages/CSD-97-946?a...](http://techreports.lib.berkeley.edu/accessPages/CSD-97-946?abstract=)

(Excellent thesis, BTW.)

<comment><AUTHOR> I'm the author of the article. I was aware of the research you link to. I enjoyed it, but research is too often focused on the formal side and too little on the user-experience side. I even mention it succintly in the article (not by name):

"I had a look at what was available on incremental parsing, and found a few research initiatives, and even mentions of a few products. But it turns out none of them was focused on the kind of problem I was trying to solve. They were either trying to improve the performance [...] or they were trying to study the formal mathematics of incremental parsing"

I mean to include other research initiatives in the above description.

Their technique is based in not accepting text edits until they parse properly, a technique which I describe in the article and which I dismissed as a hack and too basic for my goals.

My system is more sophisticated and powerful: I actually incorporate partially-wrong stuff into the parse tree! My tool highlights an incomplete 'if' block with the correct if-color, because it knows what it's dealing with!

I can also apply heuristics to choose the prefered parsing, which they don't.

There's plenty of work pending in incremental parsing, and that thesis just skims the surface (even if the academic-looking presentation may seem like it's going very deep).

<comment><USER6> I'd be interested in learning more how you implemented this.

I reccomended something similar to this for use as the parser for the VB.NET IDE, back around the start of the VS 2008 development cycle. It ended up being kind of expensive , because it required pushing changes all the way down to the text representation. All the IDE schedule time for Orcas went into supporting the LINQ features, so nobody was really interested in hearing about expensive IDE changes (by the way, I'm not disputing the choice, from a product perspective, it was the right one).

I was trying to make the parser faster, and to minimize rebinding of declarations, rather than on improving intermediate states, but I can see how it might be possible to make your stuff work.

My idea was based on several things:

1) Incremental tokenization, using a specialized editor text representation

2) Knowledge of the amount of lexical and syntantic lookahead needed by the VB grammar

3) An index from tokens to parse tree nodes

When an edit happend, the incremental scanner would then move backwards a constant number of tokens (based on some grammar properties) and then scan forward patching up the token stream until the scanner produced a duplicate token in the appropriate offset position.

The parse tree index would then be used to figure out where to restart parsing, again based on some properties of the grammar.

My focus was on producing the same trees as the existing parser, and on minimizing changes to declarations (because of all the rebinding that needs to be done), and so my incremental termination condition was based on entering a method (in the top-down hand written parser) that would generate a node of the same type as the "current position"(offset based on the edit), with the same parent, in the existing parse tree with the same starting token (based on object identity). This all worked because the scanner was incremental, which required the editor to structure it's data in a certain way

I would imagine that you probably used something similar to this, but with different termination conditions.

I would really want to see how similar (or not) what you did was to the scheme I came up with.

<comment><USER7> I'm kind of working on something similar.

One thing that struck me about C++ is that although template parsing, etc, is pretty hard, you can get a long way by segmenting the source into delimited regions. This might also speed up your semantic analysis, by allowing you to write code that's operating on a known kind of region.

For instance after pre-processing, it should be easy to find nested "{", "[", "(", "\"", "'", and "<". Segmenting the source in this way, first, might make further processing easier.

It seems that the standard parsing methods we learn in CS are optimized for single-pass speed, but not for maintainability or development efficiency. Computers have gotten fast. Using multiple passes of simpler operators seems like a good promising approach.

I see the process of parsing as some kind of folding, where you start with a linear sequence of chars and gradually fold it over and over into a "lumpy" tree.

</comment></comment></comment></comment><comment><USER8> Simpler thing that can be exploited is indentation:

        while(1) {
          if(foo) {
             if (bar) {
               ... I'm editing here!
          }
        }

it is clear from indentation that the unmatch is about if(bar). Of course in order to get the level of the open bracket you need to get the index of the first non blank character of the same line. It's a trick but in the practice may work well.

I could like GCC being able to give me an hint about this instead of pointing to the end of the file... that is, if an unmatched bracket is detected and there is something odd about indentation levels of brackets it could show:

Warning: non closed bracket may be around line ...

It is simple even to understand from the source if it's a program where indentation is usually respected or not.

<comment><AUTHOR> I plan to add indentation support to my system in the future... it's a very interesting area: gathering information from all available sources and using that to help the user.

I do believe using the history of edits, as the article describes, has a much, much greater potential.

</comment></comment><comment><USER9> In the next century, I can only hope, people will look back and laugh about how we used to store source code in textual form, and marvel at the idea of a "syntax error."

</comment><comment><USER10> I love this guy's ViEmu and definitely will pay for his new toy codekana.

</comment><comment><USER8> Btw, every time I read about "we are just at the beginning, and we already think we know all about that" I have a strange feeling. Basically nobody can tell. The contrary happened a lot of times, think about AI, it basically stopped to produce significant results for decades. The only way to know is to invest more work in the field.

And if we want to remember the advice in "you and your research" what really matters is to understand in time fields where it's worth to spend time and investigate more.

<comment><AUTHOR> Maybe it's obvious just to me? There _will_ be full AI. We _will_ create artificial brains. We _will_ fully understand how the parallel system in the brain works. We _will_ create brains more powerful than ours.

I don't think it's that far, either.

<comment><USER11> The only claim I strongly disagree with is that "we will fully understand how the parallel system in the brains works". How can you be sure? If understanding is made of abstraction, what if the brain is computationally irreducible? Our understanding will increase of course, but at some point the "explanation" of some component will be equivalent to describing all the neurons in that component and their connections.

<comment><AUTHOR> Obviously we're discussing faith and intuition here, as none of us has the facts. I don't think there is anything computationally irreducible in the brain.

About some component not being expressible as the result of simpler computations: that has to happen at some point, by definition. But that point is probably within the reach of our understanding.

All in all, I don't think there is much magic, just lack of knowledge on our part. Of course, it's just my intuition.</comment></comment></comment></comment>


Apple's new MacBook Pro has no escape key - <AUTHOR> http://www.theverge.com/circuitbreaker/2016/10/25/13409258/apple-new-macbook-pro-no-escape-key <comment><USER2> Not a duplicate, but got discussed extensively yesterday [https://news.ycombinator.com/item?id=12791672](https://news.ycombinator.com/item?id=12791672)

</comment><comment><USER3> A better headline would be: "A desperate yellow press will grasp at any BS straw".

</comment><comment><USER4> the war on vi continues</comment>


A Trans-Atlantic Trip Turns Kafkaesque - <AUTHOR> http://www.nytimes.com/2012/09/30/opinion/sunday/a-trans-atlantic-trip-turns-kafkaesque.html

<comment><USER2> As an amateur pilot, it sounds like this was an unfortunate course of events, but was handled properly. For example, when the altimeter stopped working, it was the right decision to turn back to Heathrow. When the second plane was deemed not airworthy, it was the right decision to not fly it. There are many reasons why an airplane can be unsafe to fly, and it's not always possible to prevent these incidents from happening, even with good maintenance. The best that can be done is thorough preflight checks while on the ground, and an emergency landing if issues crop up while airborne, however slight.

I'll concede that American Airlines could have treated its customers with more courtesy, offering them food and drink. It's certainly possible that American could have performed better maintenance on their planes. But it's good to know that their pilots are safe, and won't risk flying over the ocean if they have a slight (realistically irrelevant, given GPS) instrument issue.

<comment><USER3> I think the upset is about the way they were treated after the problems were discovered, and not the problems. That fact that problems heaped upon problems should have meant the service became more attentive, not less.

Agreed that the pilots did the right thing, but the customer facing staff did not.

I think the question here is is this an institutional problem with AA, or a one off. From everything I can seen, and my own experiences flying in the US, this seems to be a regular issue for AA and other US airlines.

<comment><USER4> Maybe, but after compensating for the exaggeration, I cannot find many checkable facts as to that.

(I judge the necessary amount of compensation from the statements that they turned 'halfway across the Atlamtic' and landed 'heavy'. I do not think both can be true.)

</comment></comment></comment><comment><USER5> If you haven't read _Super Sad True Love Story_ by Gary Shteyngart (author of this piece) you should.

<comment><USER6> his previous work, The Russian Debutante's Handbook, was a fun read.

</comment></comment><comment><USER7> Heathrow has always been terrible for me - except once, when I entered the UK from New Zealand without showing anyone my passport. I didn't even get it out my bag. This was pre 9/11 but it weirded me out so much that I nearly walked back to check with someone that all was ok.

</comment><comment><USER8> I will go to just about any length to avoid LHR. The only exception being when I am actually terminating in London and not transiting. It is really the most intentionally wretched airport I have ever visited, although they're all miserable in their own special ways.

<comment><USER9> "the most intentionally wretched airport"

I am curious about your choice of the word "intentionally".

Do you think that some person or persons decided to make travelers miserable _on purpose_ e.g. because they are stuck at work and are bored?

<comment><USER8> I do. It's not so benign as to be out of boredom, but out of the perverse English character. I'm sure Heathrow is some Enochian pun related to jumping between hell, purgatory, and limbo.

(Yeah, yeah, don't put on your clever pants, I know where limbo is!)

</comment></comment></comment><comment><USER10> I love the ad for Southwest at the bottom.</comment>


Chinese State Hackers Suspected of Malicious Cyber Attack on U.S. Utilities - <AUTHOR> https://www.forbes.com/sites/zakdoffman/2019/08/03/chinese-state-hackers-suspected-of-malicious-cyber-attack-on-u-s-utilities/ <comment><USER2> The damage that could be caused by disrupting utilities in the middle of winter is quite disconcerting to think about.</comment>


Climbing the wrong hill (2009) - <AUTHOR> http://cdixon.org/2009/09/19/climbing-the-wrong-hill/ <comment><USER3> What people say that they want and what people actually want are frequently two very different things. When it comes to finding product-market fit, this is obvious. There is an old quote often attributed to Henry Ford: "If I had asked people what they wanted, they would have said faster horses." It is better to look at people's actions and behaviour rather than their words when judging what they actually want.

The people whom cdixon talks to that say they want to be '"working at or founding a startup"' are lying. They are lying to themselves first and foremost and only secondarily to cdixon. Their actions speak much louder than those words. Those actions say that they want to safety and security of the job that they don't enjoy rather than the risk and uncertainty of a startup.

<comment><USER4> "Startup-founder" has become a fashion accessory. A bucket-list item. A cool factor.

As much as I don't wish for another down-turn, I will admit that it washes out the gold-diggers, the frauds and the wantapreneurs.

<comment><USER5> > He has decided he hates Wall Street and wants to work at a tech startup > (good!).

> How can smart, ambitious people stay working in an area where they have no > long term ambitions? I think a good analogy for the mistake they are making > can be found in computer science.

It's as if being an entrepreneur is the end-all, be-all of all careers. It's hard work. It's riddled with failure. It's not for everybody.

In addition, the algorithm that the author attempts to describe is called Simulated Annealing: [https://en.wikipedia.org/wiki/Simulated_annealing](https://en.wikipedia.org/wiki/Simulated_annealing)

<comment><USER4> For the system, it's like the particle swarm algorithm (PSO). Well, fine, the system will do fine. But it's really hard on ants.

EDIT: Almost all multi-agent exploratory algorithms have these characteristics: evolution, free-market capitalism.

And we all (as the species, as the beneficiaries of the system) benefit, even if 10M sperm died to give us 1K eggs to give us 1 living turtle to get back to the beach to re-spawn. The species will live. The ecosystem will adapt and thrive -- but it is very wasteful in terms of point-probes on the multi- dimensional problem space. 1K:1 or 1M:1 die, to have the one survive, because it found the niche in the problem space. That's all fine and dandy until we realize that each of us are the point-probes. We think that we are better than that. Well, maybe we are. In 1000 years, they will look back and see.

EDIT2: > It's as if being an entrepreneur is the end-all, be-all of all careers. It's hard work. It's riddled with failure. It's not for everybody.

Well, for the system, it's great. The system searches for it's maximum potential. For the entrepreneur, he's just a point-sample (in one algorithm), or a geodesic field in yours. These things are tried and tossed away as if they are trash if they don't "fit".

Nothing wrong with that ... it's as if the universe is using the human geoplex as a hive-mind to achieve something greater. But, we, as individuals, might have opinions about how we want to be treated as agents of this algorithm.

<comment><USER5> Looking up PSO, I came across Russell Eberhart's name as the co-author of the algorithm. He is also the author of the excellent book called Swarm Intelligence where I first encountered the Simulated Annealing algorithm (and many other cool ones)

<comment><USER4> I first came across it when I was hitting certain boundary conditions w/ GA/GP in the early 90s. It's pretty great. Of course, as stochastic methods go, you never know when they are going to get there. I am gratified to find recent research in the DL community going back and saying, "you know what? some of these GA/GP/PSO critiques of multi-layer NN were right, and they had something to say!". But, I'm too old and grumpy to do anything with either gratitude, or revenge or research dollars now. I just mostly tell the kids to get off my lawn.

EDIT: I'm simply saying that saying: "I told you so!" 25+ years later doesn't get me my life or my wife back. I was a misplaced, from my agent-centric- point-of-view, sample. If I could only learn to lean back and give it up for England. (just kidding)

</comment></comment></comment></comment></comment></comment><comment><USER6> >>"What do you want to be doing in 10 years?" The answer is invariably "working at or founding a tech startup"

Funny. I deal with startups all the time. When I ask startup employees where they want to be in 10 years they invariably say "Working for Google" or some version of "Working for someone more stable than this bag of cats". When I speak to startup founders, honestly and in private, the answer is some version of "On the other side of either and IPO/buyout". The employees look for stability, thier bosses cash.

The grass is always greener. I once worked in film/TV and everyone wants to hear the stories. They all think it was so much fun. It was hell. That glorious job is never what you think. Except fighter pilot. Every one of the dozen or so I've met live and embrace the stereotypes.

<comment><USER7> This is the reason I avoid startup products as much as I can. Because like you say, their primary goal is the exit. Which is usually the opposite of what the copy says on their website ("we care about the product!"), and it's totally the opposite of what I want as a customer. I'm not looking for companies who try to cheat me into becoming their customer by promising great future, only to bail out at earliest convenient moment.

</comment></comment><comment><USER8> It's important to realize that working for someone else can be the best way to prepare yourself for a startup. Sometimes the best way to climb the higher hill is first to climb the short one and then work your way up the saddle.

Starting a startup is a _lot_ easier when you're (relatively) financially secure. There's no way I would have been able to survive the first 6 months of my startup (when I didn't have any revenue coming in) if I hadn't saved up a decent amount of cash from working elsewhere (not to mention that working for others gives you important skills). The important bit is to think about this systematically: if you're going to take a job to accumulate financial and human capital, have a plan for how long you'll work there and how much capital you need to accumulate.

Being able to found a startup on your own terms (without having to desperately find angels) is very freeing and I definitely prefer it this way. My current startup is doing _much_ better than my last one because this time I'm not worrying about investors at all.

<comment><USER9> >There's no way I would have been able to survive the first 6 months of my startup

How much do you think is a 'good' amount to have saved up? I have a little over 6 months saved up but all the articles I read are like "You need 18 - <USER2> months. Minimum." which I think is complete BS, especially for a tech founder with an MVP (this isn't to say non-tech can't do it, it was more that tech people can find freelance work)

Thoughts?

<comment><USER10> There are a lot of variables in play so a perfect answer isn't possible, however, calling 18-24 months BS is almost certainly wrong. 18-24 months sounds like the ideal answer.

Note that you can spend $8k/month or you can spend $2k/month, depending on where and how you want to live while you're founding your startup. The nominal dollar amount could be a huge range.

You could also reduce the dollar amount of savings you need by the revenue in your MVP - if you're making $1k/month on a software startup you'll probably be able to net that against your monthly spend, even if most of that $1k/month is currently going towards fixed costs. The difference between an MVP that generates revenue and one that does not is enormous.

</comment></comment></comment><comment><USER11> As founder of several companies myself I always recommend people NOT to start startups. I will help or mentor them if they are really interested. Really interested people will do it anyway.

It looks today like everybody and their dog have to make a company, but first you need to have a very strong conviction that the world needs something that you provide. Starting a company is going to be very hard at first, specially when you are trained by school that effort always rewards you with results and you need a very strong force behind you to be able to face the difficulties.

The great shock is for great students that are used to have good grades or have a great job but in real startup life they struggle. In a company they will succeed but on their own they will depress and enter a death spiral. It is hard for them, for their partners, for their parents, even for their mentors.

You need a totally different set of skills than in a normal job, like the ability to manage yourself, manage risks, made decisions,make investments, choose your people, understand markets, creativity or selling yourself in front of others.

</comment><comment><USER12> There's the very real possibility that in 10 years, you'll be broke with a failed startup. Articles like this often act as if risk didn't exist, and then claim that everyone should quit their steady jobs for a moonshot dream career, be that in arts, acting or startups.

<comment><USER13> Honestly I think that risk is overstated.

I started a company, failed miserably, but it was easy to get a well-paying job with a salary and a lot of stock when I did. And the company I'm at now I joined long after product-market fit. I was still ahead in my career of people who were in the same place but didn't start a company. And I paid myself slightly less but still well enough to get by, so the only painful part was the transition between jobs. If you're a talented engineer you'll be _just fine_. I've probably had a job offer per week since then, too.

Now I've Saved up enough money, and I'll make another go. If I fail? Back to the same pretty-damn-good default position.

<comment><USER14> > I started a company, failed miserably, but it was easy to get a well-paying > job with a salary and a lot of stock when I did.

Your anecdotes are not an indication that the risk is overstated. Who knows what factors decreased the risk for you, and while you attribute it to 'engineering talent', it's far more likely to be something like more skill at using the network of connections you've established (most jobs are still filled this way).

Whatever that factor is, it isn't necessarily a common skill.

<comment><USER13> Find me a talented engineer in the Bay Area who started a company and now can't find a job. We have $5,000 referral bonuses and severe engineering shortages so I'd love to refer him or her.

<comment><USER15> Consider offering remote positions. Even if those positions are only used as a way to open new people to the possibility of moving to SF. If your shortages are severe, why limit your talent pool to the smallest, most competitive market?

<comment><USER13> The shortage at our company isn't severe, but in the bay area it is. And you do so because having people in-house is much more productive and decreases organizational cost. There's a reason people want employees in-house, and it's not mentioned much on HN.

I ran a remote company once before. I'll never do it again.

</comment></comment></comment></comment></comment></comment><comment><USER16> As a counter-point, PG had this to say about startups:

"The surprising thing here is that you can safely hill climb. If you guys are programmers... What percentage of the people here are programmers? Ok, a lot of programmers, so you all know what hill climbing is. You just do this simplest growth algorithm, you just go wherever it leads up from here. And you don't plan for the future, you don't try and think about the global picture, you just think what's going to grow this week.

The surprising insight there is that that is safe to do in a startup, that you can hill climb your way into something big. It turns out the space of startup ideas--I didn't know this, this is something I learned empirically--but it turns out that there are not dangerous local maxima. You can safely hill climb without really thinking that much ahead, and you will grow. You won't even know what you'll grow into, right? Just week by week you see.

And this works for a lot of things besides starting companies too. This would work for writing. You know, you just like work on whatever interests you and every week you try and do something more interesting, and eventually you'll look back and say "Holy cow, look, we started out way down there." You know?

So who would it not work for? It's very dangerous but there are some startups where you have to go off and build something for some number of months before you can start this sort of cycle of interacting with users. Like if you want to build a new database company, you can't just like write a version 1 in a week."

It's a passage that comes to mind from time to time. I've found that it can apply outside of the startup world, too. Interesting and easy directions in research often give insights that make harder problems easier, too.

Source: [http://www.bnjs.co/transcript-paul-graham-in-conversation- wi...](http://www.bnjs.co/transcript-paul-graham-in-conversation-with-nathan- blecharczyk/)

</comment><comment><USER17> First of all, if you know what you want to be doing in 10 years, and you are under 30, you are likely wrong. A lot of people change their plans in their 20s, and sometimes it just doesn't work out.

If you are over 30 and look 10 years ahead, it's 40 - body breaking down, retirement planning is well underway, some form of collateral, possibly a family, etc. If you're gambling on startups then, you better be damn sure it doesn't crush all the other stuff you're juggling.

Dixon's advice is misguided. He's trying to say "Don't fear starting over", which is good advice, because you will probably start over some time in your life without intending to, and it will be fine. But he's trying to make startups sound like a good idea, or "try random things" a better one.

I would not treat life like a CS problem - I would treat it like an Operations change management action. List the departments of your life that are affected by the change. List the change(s), the work needed to implement it, the expected results, a test to evaluate, and a rollback procedure. In this way you can make a risky change and understand fully what it involves, and have some plan for how to revert if things go awry. Definitely try new things, but when it comes to changes that have potentially bad side-effects, use due diligence.

</comment><comment><USER18> This is exactly why I disagree with the 24/7 work style that some startups have. I use a large fraction of my spare time (i.e. nights and weekends) to randomly drop myself on other hills.

<comment><USER7> Totally this. I'm ready to work 24/7 when I feel I'm on the right hill :).

<comment><USER18> When you feel you're on the right hill, you might still be on the wrong hill. You can climb Mt. Fuji and feel like you're on top of the world. But you're really not.

<comment><USER9> Why not just live day-to-day on whether you are happy rather than critiquing whether you are on "the right hill".

<comment><USER18> And what do you do when you are not happy? Go uphill (and it may be the wrong hill) or drop yourself randomly on new hills every day? Both are suboptimal. You should do a bit of both. Like go uphill 80% of the time and test random points 20% of the time.

<comment><USER7> That's the "exploration vs. exploitation" problem.

C.f. [https://en.m.wikipedia.org/wiki/Multi- armed_bandit](https://en.m.wikipedia.org/wiki/Multi-armed_bandit).

</comment></comment></comment></comment></comment></comment><comment><USER19> This is related to the human tendency to overestimate the danger of unpredictable risks.

The danger of a major financial disaster for a healthy and educated young person in a developed country is much lower than it seems. I know many such people that traveled across the country, some with no money or possessions to their name. None of them were broke for more than a few months, and within 6 most of them lived a similar lifestyle to the one they left behind.

The danger is much greater if you're unhealthy, uneducated, or have other liabilities, but that doesn't apply to a good portion of the HN crowd.

What a lot of people don't think about is that a true disaster will knock you out even if you have a steady job, insurance, and education. I know several people whose lives were forever changed by a lawsuit, medical bills, and health problems. These risks are barely affected by anything you can control, so in most ways it's best to just go on as if they don't exist.

</comment><comment><USER20> Kind of in a similar bind.

I work for a big company, and am paid decently well. I'm respected, but I have impostor syndrome. I really am doing nothing other than basic business logic coding. We have good tests, but no unit tests. We're not doing what I would consider as optimal programming practices, and I have not been able to convince them to change.

Yet when I look around in my city for jobs, most are lower paid than I am. Do I take the lower pay temporarily? I worry if I stay in my current job then in another 5 years, if I lose my job, no one will hire me.

I've kind of decided to make a goal for this year: Gain enough influence in my role to change some of the mindsets (e.g. convince them to introduce unit tests). If I succeed, I will have learned valuable influencing skills. If I don't, I should just find another job.

<comment><USER21> If you're at a big company and paid decently well, I suspect that you'll not have a problem finding an equivalent job sometime down the road. I had those concerns going into my own job search last year (plus at 40+, ageism) but found none of them were valid. All companies care about is whether you can code, and your ability to deliver.

Still, sure, push for unit tests. Be careful though because everyone has a different idea of what a good unit test pattern is. You might paint yourself into a corner where you have to have 100% code coverage measured by some tool or mgmt sneers. Or dev time goes up temporarily and everyone blames you for it. Know the end game you're pushing for. Unit testing is a means, not an ends.

<comment><USER20> >If you're at a big company and paid decently well, I suspect that you'll not have a problem finding an equivalent job sometime down the road.

While I'm at a big company, the company is not highly regarded in the software world, which is my concern. And I don't have anything to show for it other than: Coding on a 1MLoc code base, with mostly business logic. Occasionally I run across cases where knowing something is O(N^2) matters, but only occasionally.

I think a part of me just feels I should do slightly more challenging work, where either knowing algorithms well will help, or having some greater domain knowledge will help (e.g. Operating Systems, Parallel programming, graphics algorithms, embedded systems). As it is, I'm doing nothing that sets me apart.

I suppose that's why I want to go more into the "influencing" realm. I suspect employers will care more for my ability to change important architectural decisions for a team of 30+ people - without having the authority to do so (I'm not the manager and cannot dictate to people).

As for unit tests: I'm not too religious on it. I think it has value, but my experiences doing it in C++ also taught me that there are too many ways "to do it wrong" (i.e. make the code horrible) and only a few that will do it right. If I'm to convince the team to go that route, I need a way to ensure they "do it right" and not just do it any way they feel they should. My management feels the team in general doesn't have the ability to distinguish between the two and are pushing back.

The victory for me wouldn't be that the code base will have unit tests. The criterion I'm setting for myself is:

1\. Can I influence enough people to make this change?

2\. Can I do it in a way that is not chaotic?

I'm merely picking "unit tests" as the way to achieve those two.

<comment><USER21> No, you shouldn't feel the need to preemptively move to a "tech" company. Doing software at big tech companies isn't all that different from doing software at a non-tech company. Products are so big and diverse that you're usually contributing to a tiny little subset of some far flung feature. That said, the ceiling is certainly higher for top-tier developers.

So, I wouldn't say you should take lower pay now just to get a foot in the door. But if you do get to the point where you're hitting a glass ceiling, then certainly make the jump.

That's just the financial/career perspective. As far as how much you like the job / how much you contribute, well per my experience, the grass is always greener on the other side. When you're working on something small, you have greater influence on the product but the scope of the product itself isn't so great, and vice versa with big things (though of course there are some jobs that fail on both influence and scope). But ultimately your goals there are something you have to establish for yourself.

</comment></comment></comment></comment><comment><USER22> If one were to use a similar analogy as the author -- a startup is like a huge hill but a mirage. Once you're off of whatever you are smoking, you realize it's just a mole hill.

</comment><comment><USER23> He says "Then, a few years later, they finally quit their job, but only after having spent years in an industry they didn't enjoy, and that didn't really advance them toward their long term ambitions." It seems to me there's a glaring oversight in his statement, which is that they could very well have gained some valuable domain expertise that will serve them well if they later decide to found or work at a startup. I mean, VC's so often mention the importance of domain expertise and the way you usually get that is working at an established company first before you f(l)ounder around at a startup.

</comment><comment><USER24> Except in a startup you can discover that the high hill is a deep valley. Doesn't mean anything really. Only you can decide if you want to take that risk or not. I stopped pushing people one way or the other simply because only they can know what is best for them.

Another option is to work in a big company. After a few years there will be nothing new for you so you can bootstrap something while still having money for... food :)

</comment><comment><USER25> Leave it to a computer scientist to leave out the quantum tunneling metaphor. Well, here it is:

 _skips current hill_

"I know somebody."

</comment><comment><USER26> "Do you want to be a startup founder?" is a trick question. Most people hear "Do you want to be Zuckerberg or Musk?" Most questioners mean "Do you want a chance to be Zuckerberg?" But the real question is neither of those.

" _Over the years, I've run into many prospective employees in similar situations. When I ask them a very obvious question: "What do you want to be doing in 10 years?" The answer is invariably "working at or founding a tech startup" – yet most of them decide to remain on their present path and not join a startup._ "

"In 10 years, I want to be working extremely hard for extremely long hours, for low pay and a miniscule chance of real reward. I want to be a share- cropper on a venture capitalist's farm. I want to have a trail of failures behind me. I want to be doing the same thing over and over, because a MVP is a MVP is a MVP. I want to be ready to pivot at any instant, because shoveling everything into the crapper is better than spending an extra minute looking at another, greener pasture."

On the other hand, "I want to be working on the most interesting problems I can find" is crappy, too.

</comment><comment><USER27> Startups, that's plural, add some randomness to this hill climbing. Most startups fail and then you get pulled off of a local maximum.

But your next startup should not be exactly random. Like the VCs who invest, you should learn something from failure and you should have the lay of the land. If you don't, if it's a random walk again, then perhaps you don't belong in startups or in VC.

</comment><comment><USER28> I've sent this blog to dozens of people. While it's not universal, it offers an important concept applicable to many facets of life.

Here's another take on the same concept: [https://www.edge.org/response- detail/27033](https://www.edge.org/response-detail/27033)

</comment><comment><USER29> I wonder how the author is 100% sure that working in a startup is always better than working at Wall Street. I tried both ways, and there are ups and downs on both sides, but I liked it just a tiny bit more in big finance (though not in big banks).

Other people's mileages may also vary.

</comment><comment><USER30> Seems to me a local maximum that definitely exists is not too shabby compared to a higher hill that has a 90% chance of going dead flat on you.

</comment><comment><USER31> I went through pretty much the situation he describes: had developed videogames since I was 15, but while at university I joined the bank entity of a huge corp. I knew I wanted to do games, graphics and related stuff for the rest of my life, so after 9 months I had cold feet, got the show, accepted the offer and stayed three more years.

One of the best decisions of my life.

I learned tons of stuff that I wouldn't have learned going straight back into games. Not about COBOL or accounting, but about leadership, management and understanding the balance between business and technical needs.

</comment><comment><USER32> I honestly do not understand this metaphor at all. There are reasons why some of the algorithms are better implemented in a computer. Is there some magic that will allow me to clone myself to try multiple paths in parallel? Maybe I can speed up time so that I can climb the hills fast?

As a human, I have limited time and that places a huge constraint on what is feasible. Ignoring that and trying to draw parallels to algorithmic domain seems to miss out on crucial constraints.

<comment><USER9> I think the deeper meaning is that rather than trying to predict what path will be most optimal, you should be taking whatever step seems most optimal without trying to predict the future.

</comment></comment><comment><USER33> > _works at a large investment bank. He has decided he hates Wall Street and > wants to work at a tech startup (good!). He recently gave notice to his > bosses, who responded by putting on a dog and pony show to convince him to > stay_

Wrong choices. Better to stay a few years, then start your own company or consulting business.

And in my experience large corporations, are often more progressive than most startups (work from home, technical equipment, software stack, conferences....).

<comment><USER34> Was about to write something similar. Working for bigco can give you experience with technology, understanding of the market and contacts that you are unlikely to have coming fresh from school.

</comment></comment><comment><USER35> How bad is the ageism with respect to career length?

For example the average professional NFL player running back career length is a bit over 3 seasons. On the other hand the average lifespan in the USA is lower than real 1st world countries, at 78, but still not too bad.

So in the introduction the implication is throwing away a year of career is utterly tragic WRT "starting over" now in terms of career damage is throwing away one year like throwing away an 1/3 of their pro football running back length career or like throwing away 1/78th of their lifespan which is a rounding error?

Another way of looking at the world, is if ageism is so rampant that the dude will be permanently unemployable in the field by 30 such that throwing away one year is a substantial measurable loss, you have to consider it from a long term perspective in that a lifespan of 78 and unemployability starting at 30 means you'll live, unemployable, for nearly a half century after your career ends, half a century of wondering what would have happened if you had made that jump to try the startup. I mean, lets say due to ageism your career does end at 30, at age 55 will anything be different in your 55 year old life if you had stayed put rather than trying? So you may as well try.

You're gonna live a long time. For various macro economic reasons your career will only be a couple years. That implies you should never live to work and should only work to live. In that situation it would be foolish not to take a risk.

Extreme ageism is like terminal illness. If you know your career will be dead in five years no matter what you do for reasons way outside your control, you can complain and feel bad, or make the most of what little time you have and risk it. You're done in five years anyway no matter what, so you may as well go for it while you can.

<comment><USER21> I was very concerned about it last year, starting into the corporate job hunt at age 41, where I'd quit my last regular tech job at age 28, doing freelancing, startups (just coding, not as founder or anything), some long- term travel and misc piddling in the interim.

I had no problem at all. Got on site interviews at three of the "big four", some big industrials, some smaller companies, and a couple better-than-I- expected job offers. Maybe I got lucky or maybe it's typical, but that's my one point of reference.

The org I'm in, I'd say I'm slightly older than the others at my level, but not a ton. And it seems pretty fluid, I think within 2-3 years I'll "catch up" to the level I'd have been at if I'd not taken all that time off.

</comment></comment><comment><USER36> Going temporarily downhill is very hard for most. I know dozens of bankers who want to move to tech, but can't handle the cash paycut.

<comment><USER37> No risk, no reward.

I'm not going to convince a banker that -

but maybe that's why there are bankers and that's why there are people who race sailboats solo around the world.

</comment></comment><comment><USER38> What if the space you are searching is not a landscape with hills, but a maze?

I'm not saying it is, but the metaphor that makes the post so strong is not particularly well-grounded. Maybe we programmers tend to think about life as hill-climbing precisely because that's metaphor we often think about when solving programming problems...

</comment><comment><USER39> This article seems based on a false analogy.

Real (geologic) hills can be measured. Their dimensions and slopes are objective quantities. There is no debate about their shape.

Mr. Dixon's hills (objective functions) are the stuff of wants, dreams, and deep conjecture. Their shapes are highly subjective and highly dimensional. So much so that the 3d-terrain construct adds little to the topic – whether a gradient, simulated annealing, or any other analytic approach is employed.

To me, the article is a whimsical piece of entertainment and is not useful for even notional career planning.

</comment><comment><USER21> Or just try something outside of tech completely. You have time to explore. Yeah you'll likely end up with more money having worked at a big firm your whole life, several of my peers are more advanced in their careers than I am now, but it's not like you end up in the poor house either. I spent five years away from tech, seven in a startup, three freelancing from home before finally going back to big corp, and no regrets.

</comment><comment> real-hacker Most people intuitively know this. But sometimes it takes 10 years or even decades to climb a hill, and the probability of picking a random spot in a valley or on a plateau is high. People are just risk-averse. And I think most winners win not because of this strategy, but because they can climb hills much faster than others, thus have a higher rate to try new spots.

</comment><comment><USER40> > People early in their career should learn from computer science: meander > some in your walk (especially early on), randomly drop yourself into new > parts of the terrain, and when you find the highest hill, don't waste any > more time on the current hill no matter how much better the next step up > might appear.

I particularly like this advice.

</comment><comment><USER41> That's why humans are not very good at finding non-local maxima, and why a lot has to do with the luck of where on the terrain you are randomly dropped for your initial climb.

</comment><comment><USER42> Why will working at a startup prepare you to start your own? Wouldn't it be better working as an employee in the industry you want to start a business in?

<comment><USER9> You'll see how a startup works, funding rounds, how to set things up, etc.

In a big company, you are insulated against that and you only do your specific role. Startups require employees to have a much higher, cross-company view.

</comment></comment><comment><USER43> The grass is always greener on the other side of the fence.

</comment><comment><USER44> Needs (2009) tag in title please.

</comment><comment><USER45> I don't particularly like this kind of blog posts, for multiple reasons. First, they tell people what to do.

Second, the argument is backed up by a false analogy. The whole reason that hill climbing works, is that computers are fast. If it takes 5+ years to 'climb a hill', starting at some random point costs a lot more. Actually, it is not even clear how 'starting over at a random point' translates to real life.

Third: The point (I would say is "Try something else once in a while" \- and I mostly agree with this) could be captured in a single line. The blog post is basically the blog-equivalent of a motivational picture.

<comment><USER46> A fourth point: The landscape in tech is changing. Career in tech also requires one to deal with hills that are caving in.

</comment></comment><comment><USER47> >everyone should work on their own startup, fuck the profession you studied for years and that is stable, well earning and can teach you a lot about business!

This mentality is why the quality of HN went to shit.</comment>


Show HN: Hash Heroes – A daring Ethereum lottery game - <AUTHOR> https://hashheroes.com <comment><AUTHOR> Hi everyone, we're two software developers who have been really excited by the potential of the blockchain. We've seen a lot of ICO's and media attention in the crypto space, but we haven't seen many accessible decentralized apps out on the market. We wanted to build a great first experience for people to use an Ethereum-based app, and we wanted it to be fun. Instead of hyping up an ICO, we built this game where anyone can win big. We hope you have fun playing it, and please let us know if you have any feedback.

One component used in our game is the hash-heroes icon generator, which is available on npm ([https://www.npmjs.com/package/hash- heroes](https://www.npmjs.com/package/hash-heroes)) and GitHub ([https://khakiprojects.github.io/hash- heroes/](https://khakiprojects.github.io/hash-heroes/)). Any developers out there who want to generate cool icons based on Ethereum addresses should check it out and let us know what you think!

The Solidity contract code is available on etherscan ([https://etherscan.io/address/0x103992432927f7ed1a5b3dc0e3418...](https://etherscan.io/address/0x103992432927f7ed1a5b3dc0e34186f80b16d93c#code))

</comment><comment><USER2> This is a neat idea, clever integration with metamask too. Quick question, I hadn't used metamask before - is it legit?

<comment><USER3> Yeah, I think MetaMask is definitely the smoothest way to integrate any kind of Ethereum apps at the moment. I use it as a temporary wallet just for when I need to use dapps like this. Just send in a small amount and use it for whatever you need to do.

I guess it could be used as a serious wallet though. They give you a recovery seed so even if your computer was destroyed, you could get the backup. The only concern would be if someone got your laptop and cracked your passcode, they would have access to your funds.</comment></comment>


Request for startups: Fix conference booking - <AUTHOR> http://www.revelate.de/blog/10/2012/request-startups-fix-conference-booking

<comment><USER2> look at lilregie.com

<comment><AUTHOR> It looks nice, but for all I know the conference I was booking was using that. My primary pain points were Paypal and the separate search, booking and payments for flights and hotels, which lilregie doesn't solve.</comment></comment>


Fundamental Algorithms III - <AUTHOR> http://lion137.blogspot.com/2019/02/fundamental-algorithms-iii.html <comment><USER2> I would appreciate better naming on the variables. Some of this is hard to read through with single letter names

<comment><USER3> For me this really depends on the context. For example in a small for loop I entirely expect to see the variable "i" used (i = "index" or "iterator"). In three nested loops, I also expect "i", "j", and "k" used for each loop level. This is mostly because it is common enough convention that I don't have to think about it. Same reason I would rather see "2 + 3 * 7", vs "two plus three times seven", the information just gets in my brain faster that way without filler.

Other cases include the comparison function for a sort algorithm, where I expect "l" and "r" for left and right, and the sort function itself I expect to see "a" for array, "c" for comparison function, "s" for swap function.

But when the variables don't really make much sense, or there is no existing convention, then there should at least be a key present for what each variable means.

<comment><USER4> I've always used ii, jj and kk, etc. These are just as easy, but allow languages/editors without variable renaming to do a useful search/replace on them, because you just know you will at some point.

<comment><USER5> Most editors have at least regex search / replace. Most regex flavours allow you to do '\<i\>' or similar to specifiy word boundaries.

</comment></comment></comment></comment><comment><USER6> Are these as performant/optimised in terms of time and space complexity as they can be?

<comment><AUTHOR> Thanks, complexity, I'm gonna going through that, and adjust.</comment></comment>


A new audio format 'Reekpie' - <AUTHOR> This audio format is claimed to be better than WAVE/AIFF because of its simple structure and minimalist header (always 10 bytes), while WAVE/AIFF's size can vary.<p>Has included reference programs for encoding/decoding. (https://github.com/tryamid/reekpie) <comment><USER2> I couldn't tell from the README, but can it embed multiple stereo tracks? For example, the Rockband WAV files have 4 embedded stereo tracks (versus 8 mono ones), and quite a few audio recorders can embed many more than that. The example given suggests they are mono channels.

<comment><AUTHOR> It's stated on the README.md itself ([https://github.com/tryamid/reekpie#limitations](https://github.com/tryamid/reekpie#limitations))</comment></comment>


Apple Is Doomed: The Phony Sony Parallel - <AUTHOR> http://www.mondaynote.com/2012/04/29/apple-is-doomed-the-phony-sony-parallel/ <comment><USER2> couldn't really follow this article really well, but maybe its just me.</comment>


Scaling out complex transactions in multi-tenant apps on Postgres - <AUTHOR> https://www.citusdata.com/blog/2017/06/02/scaling-complex-sql-transactions/ <comment><USER2> The modeling in the example seems weird:

\- Why do you need a user_id in todo_items if you already associate lists to users in todo_lists table?

\- "If users have the same list ID..." Why would they?

<comment><USER3> Author here.

For the purpose of the article, adding a user ID column to the items table primarily helps with distributing the data, since all of a user's lists and items can be placed on the same node based on the value in the user ID column, which enables transactions and efficient joins.

Distribution aside, it can be a good idea to separate user data by explicitly adding a user ID column for performance and data integrity reasons. It's difficult/inefficient to guarantee inside the database that item IDs aren't reused (e.g. due to bugs in the application, serial overflow). For row-level security [1], it's also required that all tables have a user column.

Always adding a filter or join by user ID to your queries also allows for more efficient query execution. You often access many or all items of a user at once, in which case it's more efficient for the database to use an index on user ID than doing multiple lookups using an index on list ID alone (this applies generally for multi-tenant apps).

Finally, you might have to scale out one day :).

[1] [https://www.postgresql.org/docs/current/static/ddl- rowsecuri...](https://www.postgresql.org/docs/current/static/ddl- rowsecurity.html)

<comment><USER4> Second this. I used to keep tenant ID normalized but have found safety and performance in denormalizing it. It's not super fun to do, either, when you're at the point of needing to.

<comment><USER5> This is something I've ummmed and ahhhed about before. You think it's worth doing?

</comment></comment></comment></comment><comment><USER6> Is support for multi-shard transactions on the roadmap?

<comment><USER7> (Ozgun from Citus)

TLDR: We're thinking about multi-shard transactions and we'll share more updates as our timelines become concrete. In the 7.0 release cycle, we're looking at prototyping work on distributed deadlock detection, a prerequisite for multi-shard transactions.

As a quick question, we find that multi-shard transactions fall into multiple categories. Which one did you have in mind?

1\. An UPDATE / DELETE over multiple shards

2\. BEGIN; tx on one shard from distributed table; tx on another shard; COMMIT

3\. BEGIN; tx on distributed table; tx on reference table; COMMIT

We currently offer master_modify_multiple_shards() or Postgres' 2PC as potential workarounds, and know that there's definitely more work to be done in this area.</comment></comment>


Ask HN: As an entry-level developer, what's expected of me on the first job? - <AUTHOR> I graduated with a B.S. in Computer Science in September, and recently got a job with a well-known Silicon Valley company. It's not a top-tier/"Big 4" company, but its well-known and has been around for a while. Although I had one internship during college, its significantly easier compared to the work that I'll be doing, and in no way do I feel prepared.
Quite honestly, I'm a weak programmer and it takes me a long time to do things, but I do take pride in having the perseverance to push myself hard to accomplish things. During the interview I didn't know how to solve any of the technical problems, but through a step-by-step discussion with the interviewers I eventually arrived at the solution. Possibly what got me the job offer was my enthusiasm for what the company is doing. Its in the field that I'm very interested in, and am incredibly fortunate to have gotten this position.
I start in a couple weeks, but I can't help but feel like I'm going to hardcore struggle and that I somehow fooled the interviewers by making them think I'm smart when in reality I'm just a mediocre guy and they'll be pissed when they found out...
Will I be expected to hit the ground running and be a rockstar coding ninja? Will I have a mentor to help guide me through their massive code base and answer my questions? Will they patient with me if I'm slow? So many questions... <comment><USER2> As someone who work with new recruits, we are not excepting stellar contributions from day one. We are more looking for people who are willing to learn and grow, and start contributing steadily in a few weeks or months.

As a rule of thumb anyway, if you are new, you are not going to be in charge of a critical piece of the infrastructure for years to come. Likely you'll be giving relatively straightforward tasks, and once you'll have proven to be reliable you'll be given harder and more challenging tasks.

It depends on the place, but I would say that 80% of software development is rather mundane and "easy". And for the time being the harder decision will be taken by more senior people. So actually, starting is pretty comfortable and easy most of the time.

One piece of advice, do not hesitate to ask questions. We expect people to have generic CS knowledge, but it is often not enough to understand 20 years old spaghetti code. The worst recruits are the one that are too paralyzed to ask any question, and as a result you have to spend twice as long to train them because you have to guess what's wrong first.

Personally, I don't mind answering question or mentoring new people, I see it as a form of investment. Sure I am "wasting" a few hour today, but your contribution will save me countless hours in a few weeks.

<comment><USER3> Yup, don't hesitate to ask for help when you need it. Don't waste time spinning your wheels fruitlessly. If you are worried that you are asking for help too early (i.e. before you have explored the problem to the best of your abilities), then try writing an email (or something similar). I find it to be a useful way to anticipate the questions that others will ask ("Oh, have you tried X yet?", "Have you tried turning it off & on again?"). If you can't answer any of the extra questions that you come up with composing your email, then it's probably a good time to ask for help.

<comment><USER4> The process of structuring and explaining a problem to yourself via email or as before mentioned as "something similar" is available as a service: [http://duckie.me/#about_section](http://duckie.me/#about_section)

Related information: [https://en.wikipedia.org/wiki/Rubber_duck_debugging](https://en.wikipedia.org/wiki/Rubber_duck_debugging)

This method helped me alot as I found myself explaning a problem to a colleague finding the solution through the indepth explanation, wasting both of our time and focus.

</comment></comment></comment><comment><USER5> _Will I be expected to hit the ground running and be a rockstar coding ninja?_

No.

 _Will I have a mentor to help guide me through their massive code base and answer my questions?_

No.

 _Will they patient with me if I 'm slow?_

Yes, but only within a certain latitude. You'll be allowed to make mistakes, but only once - if you repeat the same mistake that's definitely considered a bad thing. You'll be expected to learn from your experience, from code reviews, and from what other developers tell you.

While that might sound scary it's also worth noting that you'll probably be given relatively simple tasks, like building forms and fixing bugs, so there's nothing to worry about. You should be able to do what's asked of you because _anyone_ who has the confidence in their ability to even apply for the job should be able to do those things. Being "mediocre" is OK. Developer ability fits a bell curve - _most_ developers are "mediocre" in the sense that they're in the middle of the curve rather than "great" or "awful" at the top or bottom ends.

Follow the company's practises, think through things, listen to other people, and find what you're good at, and you'll be fine. To be honest, I'd rather work with a junior dev who knows they're not a rockstar coding ninja but wants to learn than a junior dev who thinks they are, even if they actually are.

<comment><USER2> > Yes, but only within a certain latitude.

Another piece of advice related to that. If I am giving long, complex and detailed explanations to a new guy, and he is not taking any notes.

I have to assume that :

1\. He has a good memory, and he will remember everything tomorrow (and I am totally fine with that)

2\. He is totally oblivious of what I am talking about, and he will ask the same question tomorrow.

So please, never put yourself in category 2. Be a genius, or take notes. And always taking notes, especially the first week, is useful because you'll get a lot of information in a short time. It is good to be able to process it a bit later on.

For bonus point, if this is actually some process we have not documented and should be, take this opportunity to create a reference document for the next guys, it will be appreciated by your co-workers. You have a fresh look on things, this is valuable.

<comment><USER6> I second that, especially for the bonus point part. You'll need note anyway, one day or an other, and writing them on the wiki/knowledge/whatever of the team rather than on a sheet of paper, will also permit you to have some double check from your team members, which may clarify even more your comprehension of the subject.

</comment></comment></comment><comment><USER7> The most important thing: don't worry about it.

You will probably feel overwhelmed on your first day, probably in your first week too. That's normal. It takes time to get used to how the company works, how the codebase is structured, who's responsible for what in the organisational structure.

If it's a good company, there should be someone who you will be able to ask anything you need, no matter how often you need it. I've run multiple projects with perhaps a dozen programmers, and I try to make it very clear to new recruits that they are never bothering me. They don't usually believe me at first, but I mean it! Any significant codebase has a huge amount of knowledge and structure known only to its developers, and new guys save so much time if they can just ask a quick question than dig around for themselves. So don't be afraid to ask questions incessantly. Definitely form your question sensibly, but don't sit around feeling stuck.

Honestly, I feel the most important thing you can learn in your first day/week is who is the best person to ask about each part of the code that you'll be using, and a bit about the general structure of the code. You shouldn't expected to produce anything straight away.

Also, have fun! I still really enjoy programming after doing it full time for 15 years and hopefully you will too!

</comment><comment><USER8> First of all, you're probably a stronger coder than you think you are. Secondly, your B.S. in Computer Science (assuming you absorbed at least a tenth of the material) gives you an advantage that many "rockstar coding ninjas" are operating without. So, you're worried they'll figure out you can't code, but they're just as worried you'll ask them about the runtime complexity of what they wrote.

Also: taking longer than others isn't the same as being weaker, especially if you do a better job. I would happily pay 50% more (in time) for 15% fewer bugs, or better performance, most of the time.

Edit: typo.

</comment><comment><USER9> Like you said, the company has been there for a while. So, they had plenty of bad and mediocre coders. You won't fool them easily. They probably know the difficulties you have, yet they did hired you. It's not like they expect you to be the best but they know you have what it needs to be it. Programing is a team effort.

</comment><comment><USER10> > Will I be expected to hit the ground running ...

Very few companies do a good job nurturing and guiding new hires.

However, you can take ownership of managing the process. Read George Bradt's book New Leader's 100 Day Action Plan, while geared towards mid-to-senior level executives, you'll find many solid take-aways on managing up > [http://www.goodreads.com/book/show/16775717-new- leaders-100-...](http://www.goodreads.com/book/show/16775717-new- leaders-100-day-action-plan)

On Mentorship-- the best mentoring relationships grow organically. Regularly seek out the advice and counsel of senior colleagues, go as high-up as you can. You'll know the ones you click with. The best senior execs will actually welcome a reverse mentoring opportunity. There may some things you're able to help them on.

</comment><comment><USER11> Be sure to test your code. Even if it's obvious that it should work.

Learn everything you can from code reviews. If you are not humbled in code reviews then the reviewers are doing it wrong.

Get good at the non-programming parts of the job too. You'll be surprised at how much of your day will be spent on configuration, builds, etc. Try to learn this just like you would with programming instead of asking the senior dev to set something up for you.

</comment><comment><USER12> Listen, learn, pay attention, ask questions.

Being passionate about learning helps a lot, even if the focus of your work is dry.

I work in the insurance vertical and it is pretty dry!

</comment><comment><USER13> Your contributions aren't that important. What is important is how much you pander to the senior members of your team and other teams. Your manager will consult with them to determine your worthiness. If the senior engineers think you're "smart" and a "good fit", you're on the trajectory to career advancement.

</comment><comment><USER14> Some goals:

() Don't write code that takes the site down.

() It's ok to take a bit longer to finish something, just try to make sure it's tested well. If you release something and there's a problem, make sure you write a test for it.

() If you screw up, admit it, and let your boss know what you've done so that mistake won't happen again.

() Chill out and get hacking!

</comment><comment><USER15> You are in, that's good news because 1) they think you may come good for them and 2) they will make you come good, provided you show willingness, enthusiasm and grit. So, no worries, congrats on the job offer and good luck!</comment>


How a Machine Learned to Spot Depression - <AUTHOR> http://www.npr.org/sections/money/2015/05/20/407978049/how-a-machine-learned-to-spot-depression <comment><USER2> Whenever I see these kinds of video processing on real time, I just want to drop everything and work on that. It seems so cool! It's just like movies that we all saw while growing. Now the world is completely full of smartphones with cameras that could make great things! But somehow they don't reach us.

Might it be that sensors and processing power are still not quite there? I've just seen a Project Tango video ([https://news.ycombinator.com/item?id=9634317](https://news.ycombinator.com/item?id=9634317)) and it seems to suggest that.

BUT there are so much people focusing on these things that on one hand I feel that great things will come very soon (Oculus, etc.), but on the other hand, it's just a very risky move. The market is not yet created, everything is just a demo.

The other day here in HN someone commented something similar here: [https://news.ycombinator.com/item?id=9627754](https://news.ycombinator.com/item?id=9627754)

There is a huge risk in creating a cohesive value proposition for a big mass of people. Be reckless and you could flop like Google Glass. But once someone does that successfully, a huge market for entertainment will have just open. So my idea is to just toy with these things and gain knowledge and proficiency, but don't jump into it full time just yet. Do you think this is an intelligent (non-)move? Or just fear of the unknown? The thing is, I would also not want to move just for Fear Of Missing Out!

<comment><USER3> > Whenever I see these kinds of video processing on real time, I just want to > drop everything and work on that.

Personally, I find AI too much of a "fuzzy black box" thing to be really interested in it. I have to agree that the applications are often truly marvelous. But the fact that, for example, training neural nets is often more of an art than a science is holding me back to step into the field.

I like to work on a problem, think it through, and be 99% sure that it will work before I have even written one line of code. With AI, it is more like "let's try this and see if it works".

<comment><USER4> _Personally, I find AI too much of a "fuzzy black box" thing to be really interested in it._

That's because artificial intelligence is subject to eternally moving goalposts. Any technology which we are fully able to understand ceases to be intelligent; it is relegated to the status of mere "algorithm".

<comment><USER5> We understand machine learning itself, it's the problem space that needs to be understood. That's why it is such a black box - you never know the complexity of the model you need to build before you tackle it.

</comment></comment></comment></comment><comment><USER6> That looks cool. To get that face mesh to fit to the video in realtime like that, what kind of processing power do you need? Is this work an application of that or did they do this because now algorithms/hardware is up to the task?

</comment><comment><USER7> Funny; we've been working on the same thing at iCouch for a while now: real time predictive analytics during a video therapy session. Even funnier is that the investor community has nearly zero interest in what we're doing. I bet if we built a real-time, gluten free, organic food ordering service, we could raise $500k in about ten minutes. Our problem is determining market size; what's the market size for technology hat can predict severe mental illness situations potentially weeks before they happen? What's the market size for tech that can prevent suicides? Since nothing else like that exists, there's no way to predict how much that would be worth in terms of an investment deck. It's frustrating. The revenue generating side of the business (our SAAS for therapists,) is doing wel enough, but certainly not well enough to be able to subsidize moon shot technology that would actually disrupt mental health diagnosis and treatment. But alas, good to see NPR is giving the issue some coverage.

It is insanely frustrating when fundraising worthiness is so tied to how good you can make 10 keynote slides. Changing the world doesn't always fit into bullet points.

<comment><USER8> _Our problem is determining market size; what 's the market size for technology hat can predict severe mental illness situations potentially weeks before they happen? What's the market size for tech that can prevent suicides? Since nothing else like that exists, there's no way to predict how much that would be worth in terms of an investment deck._

Look up the number of PTSD-qualified therapists in the USA (or just therapists if "PTSD-qualified" is not a meaningful distinction). Survey a random sample of them and ask if they might use technology to help diagnosis and to prevent suicide. Multiply the percentage who say yes by the total number of therapists. That's your slide deck market size.

</comment></comment><comment><USER9> Reminds me of:

[https://simpsonswiki.com/wiki/Virtual_doctor](https://simpsonswiki.com/wiki/Virtual_doctor)

<comment><USER10> I'm always reminded of: [https://en.wikipedia.org/wiki/ELIZA](https://en.wikipedia.org/wiki/ELIZA) whenever anything like this comes up

</comment></comment><comment><USER11> The same sentence can have complete opposite meaning if it was said in an angry or calm voice. Sentiment is such an important part of human communication, that these systems will have to be incorporated in to speech recognition if they are going to be meaningful. 😉

<comment><USER12> Your comment seem phrased to imply the current Ellie system (featured in the article) doesn't read sentiment (when you write "will have to be" about incorporating sentiment- that usually reads that an existing system like Ellie doesn't have that"). From the article: "When I answer Ellie's questions, she listens. But she doesn't process the words I'm saying. She analyzes my tone. A camera tracks every detail of my facial expressions."

<comment><USER13> The comment said systems like Ellie will have to be incorporated _into speech recognition_ , to better process the context of the words being recognised.

</comment></comment></comment><comment><USER14> very cool. Not exactly related but I have been thinking if it would be possible to teach deep neural networks lie detection from video/audio feed, picking up on cues that we would normally ignore (facial microexpressions etc)

<comment><AUTHOR> That's a pertinent question in relation to the article submitted here. The main answer to your question is that there don't seem to be any invariant behaviors, or even reliable behaviors, associated with lying.[1] Some people are "naturally" capable of lying shamelessly, and many other people can be trained to lie while beating any lie detection system based on physical signs.

The best methods for detecting lying when (for example) conducting a police investigation or engaging in foreign intelligence is to analyze the liar's statements for inconsistencies. Statement analysis that prompts new questions in a structured interview is the best way to detect deception, because it's hard to make up a consistent set of story details in advance when making up a story.

[1] [http://www.slate.com/articles/technology/future_tense/2013/0...](http://www.slate.com/articles/technology/future_tense/2013/06/polygraphs_and_other_lie_detection_technologies_may_never_really_work_in.html)

[http://www.people.com/people/archive/article/0,,20079233,00....](http://www.people.com/people/archive/article/0,,20079233,00.html)

[http://www.amazon.com/A-Tremor-In-The- Blood/dp/0306457822](http://www.amazon.com/A-Tremor-In-The- Blood/dp/0306457822)

[2] [http://leb.fbi.gov/2011/june/evaluating-truthfulness-and- det...](http://leb.fbi.gov/2011/june/evaluating-truthfulness-and-detecting- deception)

[https://books.google.com/books?hl=en&lr=&id=5GjTLtibmXYC&oi=...](https://books.google.com/books?hl=en&lr=&id=5GjTLtibmXYC&oi=fnd&pg=PA41&dq=lie+detection+statement+analysis&ots=jTavMvNxPD&sig=fHfbYK6rg016vl20njSLrrCmkrs#v=onepage&q&f=false)</comment></comment>


Strategy Letter III: "Let Me Go Back!" - <AUTHOR> http://www.joelonsoftware.com/articles/fog0000000052.html <comment><AUTHOR> Joel on lowering the barriers to entry.</comment>


Why New Zealand is releasing a rabbit-killing virus - <AUTHOR> http://www.bbc.com/news/world-asia-43221704 <comment><USER2> There seems to be a lot of FUD about releasing calcivirus to kill rabbits.

Calcivirus has been released in the past to control rabbit numbers without any ill effects on the greater ecosystem in New Zealand. Rabbits should not be a part of the ecosystem in New Zealand, they are an introduced species with no natural predators (and very few introduced predators) that destroy the habitat for native birds and cause soil erosion problems.

RHDV1-K5 is not genetically engineered, it is a natural strain of the virus from Korea. Rabbits in New Zealand, having not been exposed to this strain before, have minimal immunity to the virus. The estimates for knockdown in Australia are up to 40%, they'll probably be more modest in New Zealand, due to the more varied terrain and isolated populations.

As cute as rabbits may look, they are a disaster for the environment in New Zealand, along with possums, stoats, ferrets, pigs, goats, wallabies, tahr, and to a lesser extent chamois and deer.

</comment><comment><USER3> It's seems brutal, but what introduced species have done to NZ's ecosystem is far far worse. Would anyone knowingly sit back and watch one species that shouldn't even be in an ecosystem wipe out many native species that exist no where else on the planet. The Takahē is holding on by a thread, at one point in a the 1980's it's population was down to 118, in a remote part of New Zealand (Fiordland). It was thought to be extinct, now conservationist have gone full send on the effort to protect them and set up sanctuaries on small remote islands that are pest free (you can never visit this island because they're rightly super paranoid). They were in a position of, if the hedgehogs weren't eating their Takahē's eggs, the Stoats were eating their chicks, or the Rabbits, Deer, and Goats were eating their food supply. This is just one case, since the introduction of man the vertebrate species native to NZ has halved, as in half the species are extinct, if anything they're still not doing enough. The Moa is just one of many species we'll never get to see, the Haast Eagle is another, they were starved to death. [https://en.wikipedia.org/wiki/Haast%27s_eagle](https://en.wikipedia.org/wiki/Haast%27s_eagle) they also hunted Moa's which is pretty epic, largest bird of prey to have existed on earth.

</comment><comment><USER4> I was disappointed by the partial/early release of RHDV1 back in the 1990s in Australia. Quite apart from being terrible biosecurity (that somehow it got released from secure facilities before time) I belive it kind-of backfired, establishing partial immunity in the wild before the official release. Maybe the news of the time sensationalised it, but it felt like a mis-managed situation. I hope this RHDV2 release goes well. (I know rabbit owners, I realize how stressful and upsetting this story may be, but feral rabbits are huge problem)

<comment><AUTHOR> Enough of a problem to resort to bio warfare?

<comment><USER5> Yes.

This is also a country which wants to eradicate rats, possums, stoats, feral cats, and several other predators by 2050. See New Zealand aims to become predator-free by 2050 , linked to from this article.

See also "The Big Kill - New Zealand's crusade to rid itself of mammals." [https://www.newyorker.com/magazine/2014/12/22/big- kill](https://www.newyorker.com/magazine/2014/12/22/big-kill) ("mammals" here does not mean "all mammals").

<comment><USER6> New Zealand ridding itself of sheep and people would be an interesting choice.

</comment></comment></comment></comment><comment><USER7> Beware of messing around with large systems! Your proposed "solution" will most likely backfire in ways you don't even imagine!

<comment><USER8> Your comment is rediculous.

Rabbits are a non-native species what were recently introduced and are causing significant damage. It's very well understood what a NZ without rabbits would be like; it would be _like the NZ that existed before rabbits_. That's the point.

(And also like the smaller islands that are already rabbit free.)

<comment><USER7> Humans are notorious for not being as smart as they think they are.

</comment></comment></comment><comment><USER9> Maybe it will actually help, but self-righteousness of the proponents of such methods never ceases to amaze me. It actually makes the plots of all these stupid sci-fi movies seem somewhat plausible. You know, the movies where some technocratic forces (usually military or research group) always do something so obviously stupid, that it just couldn't happen in real life, with security protocols and all. You know what happens next. It's borderline hilarious and terrifying.

I mean, first you (well, your grand-grand-…-grandfathers) introduce new species to the land. They are absolutely harmless, you have plenty of them at home and would like to have even more. What can go wrong? When you learn the answer, you try to fix your fuck up while your parents don't see and introduce some more new species that apparently fought off these first species back at home. After all, you are smarter now, you know biology and stuff, you know how one animals eat the others and can play with this stuff knowingly. Well, this does the trick, your first little fuck up gets eliminated, but now that second animal dominates the whole new continent and overall situation got just much worse. You try this several times and it gets trickier every time, but you are so sure of yourself, so educated and smart that you just cannot let go, you are sure you can fix it _this time_. So you artificially construct a virus to wipe off the harmful population. It seems to help at first, but soon they get immune to that virus and really good at spreading this virus around. Then the virus mutates. Scrolling forward, there's no single kangaroo left alive on the continent, rabbits now can produce nuclear weapons and you still have a new, final solution that surely will fix the situation this time. Like artificial kangaroo immune to radioactivity or something, idk…

<comment><USER5> While entertaining, your description doesn't come close to matching what's going on in New Zealand.

Rabbits were first brought to NZ in the early 1800s. They caused problems by the 1870s. [http://nzetc.victoria.ac.nz/tm/scholarly/tei- DruExot-t1-body...](http://nzetc.victoria.ac.nz/tm/scholarly/tei- DruExot-t1-body1-d9.html) . In 1947 the Rabbit Destruction Council was formed. So this isn't a "when you learn the answer" but when your g'g'grandparents learned the answer.

It does not appear that any animals were introduced to NZ in order to kill the rabbits. Perhaps I'm wrong? Ferrets can be used to hunt rabbits, but from what I gather they are not effective as a population control method.

The RHDV1 K5 virus is not artificially constructed. "It is a naturally occurring variant of RHDV1, originally found in a rabbit breeding farm in Korea." \- [https://www.landcareresearch.co.nz/science/plants-animals- fu...](https://www.landcareresearch.co.nz/science/plants-animals- fungi/animals/vertebrate-pests/biological-control-of-rabbits/faq) .

More likely, you are thinking of Australia, since NZ isn't usually considered a continent and since it doesn't have kangaroos.

<comment><USER9> You think too much about details. It wasn't supposed to be taken literally, I'm not talking about NZ in particular, yes, Australia's case was taken for inspiration, and, yes, I'm aware of RHDV1-K5 not being artificial per se.

It actually feels weird to explain that and, no offense, but I think the fact you are taking it so literally is actually the essence of what I'm trying to say here. The details don't change the general fact we have a history of fucking things up, because "we know science" and "have verified all the details". And the silliness of all the mistakes of the kind I'm talking about here is essentially the same — while fully admitting we don't know all the details, some people are too eager to ignore that and to feel self-righteous on the basis of checking _all the known details_ and not seeing a problem.

This isn't about RHDV1-K5 — if I had some serious educated concerns about it, I wouldn't voice them over here (at least not only here). Maybe there won't be any problems this time, I don't know and I surely hope so. But we have a solid track of proving otherwise and, I'm sure of that, we are not done with making mistakes yet.

<comment><USER5> It's odd to read that I think too much about details, then read you complain that people don't think enough about all the details of what might go wrong.

Abstractly, what you say makes sense. It's been the heart of much of the opposition to ecosystem intervention for decades.

But when it gets down to the details, the question is, when should we try to intervene?

Your comments appears to be "never, because we don't know the consequences."

Which is fine. There may be good reasons against it. But if you justify it with a story line better suited to a science fiction movie then how much weight should we place in your opposition?

Or, going the other direction, what sort of response would you want which would make you feel more comfortable about the plan to use RHDV1-K5?

</comment></comment></comment></comment><comment><USER10> Depends on what they expect to happen. This has been done in Australia at least twice with different agents.

[https://en.m.wikipedia.org/wiki/Myxomatosis](https://en.m.wikipedia.org/wiki/Myxomatosis)

<comment><USER11> They've done it in New Zealand before as well, illegally (or something similar at least). It worked a bit, in one region, then failed. The result was farmers wound up fighting a massive population growth of rose hip plants which took over as much as the rabbits did.

At least that's what some old guy told me when I was walking through the South Island on the TA.

<comment><USER5> [https://en.wikipedia.org/wiki/Rosa_rubiginosa](https://en.wikipedia.org/wiki/Rosa_rubiginosa) points out that the rose hip plant is an "environmental weed" in NZ, and that "Growth from seed is aided by the reduction in competing pasture by rabbits." It links to [http://www.massey.ac.nz/massey/learning/colleges/college- of-...](http://www.massey.ac.nz/massey/learning/colleges/college-of- sciences/clinics-and-services/weeds-database/sweet-brier.cfm) which says:

> Pasture competition prevents new plants from establishing, though > established plants are very competitive. Rabbit infestations have helped the > spread of sweet brier by reducing pasture vigour. Cattle, possums and birds > spread the seed by eating the fruits ("rose hips") produced around the > seeds.

</comment></comment></comment><comment><USER12> I'm surprised that there is not a big enough market for rabbit meat to take care of this problem elegantly.

I haven't had rabbit since I was very young but I do remember it being absolutely delicious.

<comment><USER5> "Elegantly"? Economics and ecology have never worked together in an elegant fashion.

We would need orders of magnitude more hunters in order to eradicate rabbits from NZ. That's expensive. Rabbits simply aren't tasty enough to justify that effort.

If the market demand for rabbits were to increase drastically, one market response would be to raise more rabbits on rabbit farms, which is cheaper than game rabbit.

An increase demand would also result in increased rabbit hunting in Australia. So long as Australian rabbit meat is cheaper than hunting down the last of the NZ rabbits, NZ rabbits will remain in the ecosystem, ready to, _ahem_ , bounce back once the economics changes again.

Nor are people stupid. If rabbit hunting brings in huge amounts of money, landowners in NZ are not going to eradicate all of their rabbits for the sake of short-term profits.

</comment></comment><comment><USER13> This is a bad news, we dont understand ecology enough to toy with it with viruses. Killing and Trapping is a much safer choice, we never know what mutations the virus might acquire and become a larger threat to ecology and us. This is why capitalism could be bad when a Biosecurity company backs such attempts. I am surprised who suggests such ideas to the government.

<comment> quixoticelixer- You have absolutely no idea what you are talking about, killing and trapping, will not and do not work. It is all but impossible for the virus to mutate to infect a desired species.

<comment><AUTHOR> Are you telling us this particular virus cannot mutate? Because spreading it to a large population of target host species confined on an island would present plenty of opportunity for mutation.

<comment><USER5> That would indeed be a silly claim as RHDV1 K5 is itself a strain - a mutation - of RHDV1. It was found in a rabbit farm in South Korea.

The claim is that it is all but impossible for this strain to mutate to infect another species. Not that it's impossible for the strain to mutate.

RHDV1 is already endemic in Europe and elsewhere. There are plenty of opportunities for that virus to mutate.

None of the mutations affect anything other than the European rabbit.

<comment><USER13> I dont think it is a correct claim, the current form of HIV has mutated from a similar virus found in Guerillas. The first anti biotic was produced from cowpox boils. It is the same principle Other species can contract a mutated version of the virus, spreading it in such a large scale posits a threat because we dont understand ecology enough.

<comment><USER5> "All but impossible" means "very nearly impossible", not "impossible."

Certainly there are diseases which can cross the species barrier.

Foot-and-mouth disease, quoting [https://en.wikipedia.org/wiki/Foot-and- mouth_disease](https://en.wikipedia.org/wiki/Foot-and-mouth_disease) , can infect "cattle, water buffalo, sheep, goats, pigs,[4][5] antelope, deer, and bison. It has also been known to infect hedgehogs and elephants;[3][6] llamas and alpacas may develop mild symptoms, but are resistant to the disease and do not pass it on to others of the same species.[3] In laboratory experiments, mice, rats, and chickens have been successfully infected by artificial means, but they are not believed to contract the disease under natural conditions.[3] Humans are very rarely infected."

On the other hand, some diseases are species-specific. Smallpox and polio are two humans diseases which are not transmitted to other animals, which has helped us eradicate (or nearly so) those diseases.

RHDV1 K5 appears to be in the latter category, in that it has not been seen to infect even other species of rabbit, much less more distantly related animals.

<comment><USER13> Thats a valid point if it has been observed in lab conditions. i still feel its not entirely safe, but if it has been tested as you say on a smaller group then probably this risk can be taken.

</comment></comment></comment></comment></comment></comment></comment><comment><USER14> They say hunting is not adequate to solve this problem, but I would think a few boat loads of hunters from SEA could not only measurably reduce the population of rabbits but also provide a lot of food and fur.

I'm not at all advocating killing rabbits for food or fur, but it's at least more human (and less wasteful) than sickening them and having them suffer 2-4 days before they die.

<comment><USER15> I don't think you understand exactly how many rabbits we have, remember they have no native predators - NZ didn't get land mammals until humans showed up in ~900AD

<comment><USER14> Well, let's hope the virus does exactly and only what it should. It would be a shame for it to mutate and wipe out something else accidentally.

<comment> quixoticelixer- It would probably be a good thing for it to do that.</comment></comment></comment></comment>