rowborg

This is really impressive! Great job.

One small piece of feedback… There were a couple times where I asked to learn something, and it asked me to repeat a phrase back, which was great. But when I repeated it back, I know I didn’t quite nail it (eg perhaps said “un” instead of “una”) and rather than correcting me, it actually told me I did it perfectly. Maybe there’s some tuning with the prompts that may help turn down the natural sycophancy of the model and make sure it’s a little more strict.

Keep up the great work!

That's just the Leonhart. There are a number of other manufacturers that are approved for various types of tournaments including Tornado, which is most common in US tournaments and has a 3-man goalie bar.

https://www.tablesoccer.org/tornado

Official tables can have either style.

There are quite a few tables that are considered tournament grade by the various table soccer associations, including ITSF (I think at least six manufacturers at this point?). In the US, Tornado is the most common tournament table by far and has a 3-man goalie bar, but many European tables like Bonzini or Garlando have the 1-man and raised corners.

Factoring work into independent modules that are owned by teams does not preclude active and vigorous collaboration. It just means you don't need a giant list of approvals or manual actions from people all over the company in order to ship something or make a decision.

Oh dear, he got me.

  <script type="98f4b28488f8bdfd1252d4f9-text/javascript">
    try {
      if (document.referrer) {
        const ref = new URL(document.referrer);
        if (ref.host === 'news.ycombinator.com') {
          window.location.href = 'https://en.wikipedia.org/wiki/Freddy_the_Pig';
        }
      }

      // If you're reading this, you've entirely missed the fucking point. Go touch some grass.
      if (Math.random() > 0.9) {
        window.location.href = 'https://en.wikipedia.org/wiki/Special:Random';
      }
    } catch (e) { }
  </script>

A couple things:

* The guidance is to allow teams to do work independently in parallel, not give them no direction or strategy of what to work on. Without small discreet teams that can operate without a bunch of external blocking approvals or manual processes, you simply will not get work done as the org scales because your productivity will quadratically approach zero.

* He addresses the cost of coherence (both its creation and its absence) in the post, which is worth reading in full. He also talks about how to structure a product portfolio in order to avoid the “confounding competing solutions” scenario.

In short, you’re not wrong, but the downside you outline is tractable—centralization of decision making is not.

Coda Hale's "work is work" is my favorite analysis of this topic, because of its focus on axiomatic mathematical upper bounds on productivity and how you can avoid hitting them:

https://codahale.com//work-is-work/

The solution, as mentioned by other comments already, is for leaders to ruthlessly focus on keeping work efforts as independent as possible:

> When presented with a set of problems which grow superlinearly intractable as N increases, our best bet is to keep N small. If the organization’s intent is to increase value delivery by hiring more people, work efforts must be as independent as possible. Leaders should develop practices and processes to ensure that the work efforts which their strategies consider parallel are actually parallel. Shared resources should be continuously managed for contention, and where possible, the resources a group needs should be colocated with that group (e.g., if the work involves a lot of design, staff a designer to that group). Combined arms doctrine isn’t just for soldiers.

Met my wife of now 13 years at age 30 via a group dinner put together by a mutual friend. A good friend of mine just met the love of her life at age 39 via online dating. Don't stress about getting older; when you find the right person it will just click.

> I have no idea what hobbies to pickup or where to search for places where people hang.

I suggest that instead of finding a hobby that you think will help you meet people, you focus on what you love to do. If it's a solo activity (e.g. gaming, coding), go figure out how to do it socially (meetups, game nights, hackathons etc). Follow the stuff you love and use it to connect to people. It will allow you to be authentic and meet people who have the same interests as you and share your values.

Hang in there!

That was also my first thought (injection all the way down), but doesn't this reduce the problem to enforcing simple character escaping?

The article indicates that it was 841's mother who was likely fed by humans. 841 was born in captivity and care was taken to prevent human association:

The pup was raised by her mother until she was weaned, then moved to the Monterey Bay Aquarium. To bolster her chances for success upon release, 841’s caretakers took measures to prevent the otter from forming positive associations with humans, including wearing masks and ponchos that obscured their appearance when they were around her.

I had a major issue with Bank of America that I could not get any support on. I filed a CFPB complaint and was directly contacted by a representative the next day who solved my problem.

Complaints are a big deal for these banks and fintechs; if the complaint level gets high, the auditors show up and plant themselves in the office and start digging. And when they start digging, they find things... things that end in public fines and damaging press releases.

When a developer wanted to build a 5 story condo building on an entire block across the street from the SF property I've owned for the last ten years, many of my neighbors opposed it. I wrote to our building's ownership and told them that we should support that project and that my only question was "can they add a few floors?"

Repeal prop 13 and my taxes will go up enormously--and I'll vote for that repeal at any opportunity.

Some of us do actually believe that the long term common good is worth sacrificing our own personal short term gain.

It's a fair point. What makes Lafayette a good place to build without increasing sprawl or traffic that it is right on a BART line. "More of everything" should probably be caveated with "more of everything near public transit".

For purposes of discussion, let's take it as a given that a work-hire tests are the best way to screen candidates.

The effort required to administer an on-site work-hire test is non-zero, therefore I cannot administer such a test to every applicant.

I therefore need a way to determine who to bring on-site, in order to administer such a test. I cannot phone screen every single applicant due to the cost involved.

That process could also be a work-hire test of some sort (e.g. a remote coding project), but regardless of what has been said on this thread, many good applicants will drop off at this step. I know this empirically, because I've experienced it, many, many times.

Additionally, the people who tend to drop off because of this extra effort tend to be senior applicants, who often have multiple offers from multiple companies due to the competiveness of the current hiring market. It also disproportionately drives away passive candidates, who are often the best candidates, because the best candidates are often not looking for work (since they are good, people who have worked with them previously want to work with them again, and they get poached).

So I need some method of sourcing and filtering candidates down that is non-intrusive to both our development team AND the applicant. This is the reality. This simply has to happen in a startup's hiring pipeline.

Currently, most companies do this by looking at resumes. That is obviously sub-optimal.

Any suggestions for alternatives?

EDIT: spelling.

I posted this as a comment on the original post, but will make the point here...

Large organizations are often more dysfunctional than small ones, yes, especially when it comes to building software. But that doesn't mean they aren't filled with very smart people. The fact that enterprise programmers can't get hired at startups is not, in my opinion, a reflection of the dysfunctional nature of software development at large companies, but of a mismatch in expectations about how to communicate your ability to do your job.

As an example: one pattern I’ve seen that consistently holds enterprise programmers back in startup interviews (especially in phone screens and technical screens) is the inability to effectively articulate the projects they’ve worked on. Enterprise programmers have often worked on optimizing one small part of a very large and complex system that no one person may understand completely, and in my experience, they often cannot describe that system clearly or holistically. Startups usually need people who can build a system end-to-end, and when an enterprise programmer doesn’t seem to understand their own projects, it reflects very poorly. I see this pattern way too often.

My suggestion (and obviously this is a gross generalization) is for enterprise programmers who want to work at startups to practice being able to clearly and consisely explain what they worked on and how it fit into the overall product. Startups will care more about this than showing, for example, a deep understanding of how Java's various memory pools work (even if they work in Java).

i think you meant

  filter -> open now -> sort by -> rating

;)

This has been ongoing for a while now (see http://fortune.com/2015/03/11/seed-surge-series-a-crunch/) and is due to the commoditization of computing infrastructure and the size of the internet audience, which allow very small teams to generate significant levels of revenue/traction. VCs now expect more at a Series A because so much more is now possible.

Happy to add my congratulations to the wave of orange users already doing so... it's clearly reflective of the impact you've had on so many YC startups. Thanks Sam and can't wait to see where you take YC next!

Absolutely, indentation helps catch this when writing.

When I've seen this happen, it wasn't because of a semicolon added when the code was written. It was someone accidentally adding a semicolon to a line later, without realizing it. Unless they then went to the next line and hit the "fix indentation" key, they didn't catch it.

One downside to non-braced conditionals is that a semicolon accidentally placed after the conditional will cause the block to always run, e.g.:

  if (null != foo);
    bar();

This is valid code in C and Java, and bar() will always run in this case.

Having seen people waste hours on such a semicolon, I always use braces, even in one-liners, because I never know when someone is going to break it out into multiple lines later:

  if (null != foo) { bar(); }

I think this is absolutely correct. In particular, it gives you a socially acceptable (and externally validated) excuse to ignore many of other commitments in your life for three months so you can get your idea off the ground. It's a lot easier to tell your family that you're going to quit your job and hole up in a cave working on a crazy idea for 3 months if you can hand them a New York Times article on YC and explain that you are going to be a part of that thing they keep reading about.

I built this for our company using IFTTT; we have a little blue siren that goes off when a user converts. It's powered by the production app sending an email to IFTTT which power cycles a Belkin WeMo. Very simple, and it works quite well (excepting for a 10 second or so delay between the conversion and the siren going off).

In the above proposed methodology, Americans are exempt from the mental tests because those types of tests have questionable legality in the US, not because Americans do not need to be screened.

I find the idea of a bricked Curiosity horribly depressing. Let's make sure to wait a FULL FIVE MINUTES before rebooting, ok guys?

Just curious, why do you say this? Most lockups are structured in such a way that they are binding whether or not you continue to be employed by the company. Your shares can only be sold via the company stock plan manager (often the underwriter) and they will enforce the agreement.

Is there any reason you believe FB's lockup is structured differently?

Personally, I completely agree. Code is written once and read often, so when working with any codebase where contributors > 1, readability should win over writability every time.

This should not be an argument against language constructs which make languages more expressive, but there seems to be a trend where as languages move toward the functional end of the spectrum, they take on more and more terse and cryptic syntactical structures.

I've always felt that good code should read like a book. This can be reconciled with prefix notation, but not with overloading odd characters as operators.