Isn't the most common scenario for these enterprises where the programmer's customers grow beyond his ability to support just by himself?

So he starts adding people to handle the portions that he cannot, efficiently, handle himself.

If you're going into this wondering what the "ratio of senior programmers to intermediate and junior programmers" should be then I think you've skipped too many steps.

The same with "different tools and/or languages". The 2nd programmer uses exactly what the 1st programmer uses. The idea is to provide support for the founder so he can focus on what he is good at.

I'm thinking that there should be some mechanism for funding X scholarships in STEM for X visas of the H1B1 type.

Corporations receive 100 H1B1 visas this year, then 100 STEM scholarships are also provided this year. Funding via taxes on those corporations.

At least it would make it easier to graduate in a STEM field without the massive debt.

My first question is what needs to be allowed in order for this to work? Do I have to whitelist sites in adblock? NoScript? Do I have to abandon those addons?

What about any of the anti-tracking stuff I use?

And, lastly, the main reason I use all of that is because I got very tired of clicking on a site and WAITING FOR ALL THE SHIT TO LOAD AND RELOAD AND RERELOAD.

I might use this. I might not. But there isn't enough information available right now to tell whether it will be better or worse for me than what I'm doing today.

There are, probably, several alumni who are employed by those companies who would not want to see the publicity of their high prestige alma mater taking a public stand against their business.

Sorry, kids. Part of the attraction of Harvard is the business/political connections it gives you.

My guess is that someone important was scammed OR the money got to the level of "important" for the banks. This has got to be one of the easiest things that the FBI could track and bust.

A related question, though. As anyone who's ever done support knows, the average computer is awash with problems. How different would the situation have been if the scan had been real instead of a scam?

https://www.senate.gov/legislative/LIS/roll_call_lists/roll_call_vote_cfm.cfm?congress=113&session=2&vote=00282

As you can see, it was pretty much along party lines.

One can fix an engine or even put it together the other designs it.

I think that, in this case, it is more like someone trained to change your oil at one of those 5 minute places.

Someone working there CAN move on to bigger things, but it won't be because that training taught them how.

However, I still say it's correct that even on the basis of a small sample, you can rule out claims about the background population.

You can say that but you are wrong.

With a small, non-random sample you cannot say ANYTHING about anything.

You reach in, grab a ball at random and pull it out, and see that it's red.

Random is not the same as non-random.

A small sample size that is random is NOT THE SAME as a small sample size that is non-random.

It's trivially true that "any small sample is going to have some non-random attributes", but that doesn't mean the sample itself isn't random, ...

Again, your sample was not random.

No matter how many times you try to imply/claim that it was random, it was not random.

Some Slashdot commenters have shown that they need an article about basic statistics, more specifically what can be inferred even from a small sample.

There are lots of people out there (and here) who do not understand basic statistics. Bennett Haselton is one of them.

The FIRST problem is not the small sample set. It is that the small sample set is "some people on Amazon's Mechanical Turk who are willing to take a survey for $X". His sample set is flawed.

And his home-written "survey" is also flawed.

So his math is meaningless. Garbage-in, Garbage-out.

In order to deal with the flaw in his sample set he'd have to have a much larger sample set. OR a properly selected sample set.

THEN he'd need his "survey" re-written.

And only then could he try his hand at the math. He hasn't even explained what his margin of error is or which method he used to calculate it. BECAUSE HE DOES NOT UNDERSTAND STATISTICS.

Anyone who believes that buying private links into a providers network is the same as your traffic getting paid priority knows jack shit about network ops.

The Fallacy of Equivocation.

You've substituted the more specific network-jargon "priority" for the usage of "priority".

Once Netflix PAID Comcast then Comcast gave Netflix PRIORITY access to the Comcast network. The PRIORITY access means bypassing the choke point that Netflix was previously restricted to.

No one is saying that Comcast changed the QoS or priority of individual Netflix packets. But that is what you are denying.

Now I'm sure a bunch of people (who are not network engineers) are going to argue over the wording and philosophy as to whether or not buying paid links into a providers network constitutes priority or not. It's not.

Again, you are substituting a more specific network-jargon usage of "priority" that no one other than you is using.

And you are denying something that no one else is claiming.

That is the Fallacy of Equivocation.

The only difference that buying direct links in meant was that they got to skip the congestion in the peering points.

Which is what everyone, except you, is saying.

Once Netflix paid Comcast, Comcast users could suddenly get better access to Netflix.

But Comcast refused to do anything to address that congestion UNTIL NETFLIX PAID THEM.

It is the only machine on the network that uses that IP.

ON A WIRED WORKSTATION ON THAT NETWORK, go to http://www.whatismyip.com/ and see if the IP address it reports ends in .157.

ON A WIRELESS DEVICE ON THAT NETWORK, do the same.

This will tell you whether a machine on your network may be sending spam from the same address as your email server.

The traffic coming from my server is so ridiculously small, that I was shocked to begin getting messages like these from those email providers.

Not your server.

Your network.

Monitor the traffic going into or out-of your cable modem to see what is happening on outbound port 25 for that IP address. Do this for 24 hours.

Move your mail server to a different IP address if that is possible. You have 5 addresses, right?

The rejection messages are saying that YAHOO and HOTMAIL are seeing too many messages from your specific IP address.

GMAIL is accepting the messages but flagging them as spam.

It is extremely unlikely that three competing services are all using the same SMTP-blacklist (that they refuse to identify) to reject messages.

So, in other words, both of these messages are crap and not accurate.

They are similar messages from two different services. It is very unlikely that they are both claiming the same problem ... incorrectly.

You've had those IP addresses for 2 years without problems so it probably is not a pre-existing issue with the IP addresses.

Do you have a firewall that you can configure to monitor outbound port 25 attempts from your network? Or do you know how to use a sniffer such as Wireshark to do so?

Or can you move your email server to one of the other IP addresses you have? And see if it is still blocked?

Right now it is looking like the problem is on your network. Not Comcast and not GMAIL or YAHOO or HOTMAIL. I might be wrong. But if it were me, I'd test my network first. Otherwise, even if you do get through to YAHOO or HOTMAIL they'll look at the logs and say the same thing.

Deferred: 421 4.7.0 [TS01] Messages from XXX.XXX.XXX.XXX temporarily deferred due to user complaints - 4.16.55.1; see

That seems to indicate that at least one of your recipients at YAHOO is actively flagging your messages as spam. Maybe they have incorrectly written a rule that is doing so.

Deferred: 421 4.7.1 [TS03] All messages from XXX.XXX.XXX.XXX will be permanently deferred; Retrying will NOT succeed.

... and ...

Deferred: 421 RP-001 (BAY004-MC5F24) Unfortunately, some messages from XXX.XXX.XXX.XXX weren't sent. Please try again. We have limits for how many messages can be sent per hour and per day.

And that one seems to be saying that your IP address is sending too many messages.

How many messages per day are you sending?

The code is what matters. Here's a site with a bit more info:
http://tools.ietf.org/html/rfc3463

If HOTMAIL is rejecting with one code but YAHOO is rejecting with a different code then there may be THREE issues for him to deal with.

And since he is running a server he will most likely be using port 25. Encryption may change that. But for initial testing purposes he should skip encryption for HOTMAIL and YAHOO until he can determine why his messages are being rejected.