i__believe

This is how I prefer it. Give me the lay of the land, if you will, then I can dive into what is interesting.

Hire too many expensive engineers?

I don't think that's why people buy consumer reports. At least for me it's about getting a professional review in the context of the product as well as against others in the same category from a source whose only interest is keeping the customer (me) informed. I'll admit that limits the selection of the products reviewed, but I'm OK with that trade off.

I think what you're describing could work well for Angie's List though (also a customer of theirs).

Question: how does one go about finding that number?

One thing you may consider is having private or invite only communities. Almost all the offerings out there are for public communities, which leaves in house self help an untapped market.

Slack doesn't, unless I'm not finding that feature after a year+ of using it.

So they don't waste cycles on something not part of their core business or competency? Pretty standard reasons to pay someone to solve a problem. I think what this really showed is Dyn was not as competent in mitigating as what people thought.

It's been really great, and reporting issues and small pull requests has been super easy so far. Not really what I expected from a company like walmart so I was pleasantly surprised.

The only fundamental disagreement I have with it is how the "client" folder is organized by default. I think it's a mistake to organize by the type of file (component, reducers, etc). Instead, the organization should be centered around the real use (pages, resources, etc.) Explained in more detail here, https://medium.com/@alexmngn/how-to-better-organize-your-rea...

I understand that's personal preference, and my preference is born out of seeing more than one react app become a tangled mess because isolation was hard to understand based upon file structure.

Have you looked into electrode.io? It's the total package with testing, server side rendering, optional above-the-fold rendering, profiling, etc.

It took about half a day to get used to it, but I enjoyed not having to make the decisions over and over again and handles the basics as well as advanced use cases.

I use it as a news site as well, and to resolve customer support issues. On that topic, it's simply amazing how much more responsive a company is if you contact them about a an issue on twitter than in any other form of communication.

I believe twitter should segment and provide platforms for specific types of users.

I'm pretty sure that's a good illustration of my point.

Great signal for what?

Exactly, and this is a big problem where I work. I believe code should be readable, even by those with only cursory knowledge of the language. Object shortcuts is also a problem I think. For example, I had a method like this:

const getObj = (id, store) => { return { id: id name: store.something.name }; };

The linter gave an error on it because I used {id: id}. It was like the linter was trying to make my code harder to read.

I think es6 in the wrong hands quickly falls prey to the problems of ruby/scala where it can become incredibly terse and hard to parse unless you are used to the author's particular style.

Often times I see this argument made, and on it's face seems like a good one.

However, experience has proven that it is difficult to actually contribute--even in active repo like npm. Every project has there own standards and unwritten rules. Further, many repo maintainers are unresponsive after initial contact, adding frustration to an already frustrating process of getting work put in.

Let's take npm/npm as an example. There is no easy to find contributing guidelines, thousands of open issues, and pull requests that have been open for months where the author requests more info so they can complete their work but without an answer. All of this leads to a contributor-hostile experience.

I think we as a community should consolidate the contribution process, and start treating that as a product and gets the same love the code does.

Why would I want to use different services? I (personally) use godaddy, my company uses namecheap.

Both seem to be doing fine and we check in on them once a year.

I've received these as well, but it's always been "Hey, it's been 6 months since your last oil change with us -- come on in!"

I could very easily see if you go to the same mechanic and they input your mileage between visits and a system having a reasonable chance of getting scheduled maintenance correct based upon time or average mileage.

I've never heard of a company pulling data from a car OTA to do this type of work. (some car insurance companies are a different story though)

I think there are a lot of nuance to this statement. After a few years on the start up scene, I believe that if you are using a "duck" typed language your core concepts should be tested without exception (for example rails and django models). The farther you get away from these core concepts, the less your tests need to be there and the more likely that code is to change.

In addition, if you are truly in the earliest stages of your startup (pre-revenue/traction) the tests are not needed -- but you have to be _very_ aware that you are making a tradeoff for sheer velocity and you will have to pay the price later on. I've seen too many startups fail to pay the price and it comes back to haunt them and reduces their overall velocity.