louischatriot

Raising the price for tld would actually be a good thing, as it would make "domain investing" (domain hoarding) unprofitable.

Let's say a .com costs $1,000 per year. For a legitimate business / organization, that is a trivial cost. For a domain hoarder, that makes keeping domains by and large unprofitable.

Killing this parasitic activity is a good thing.

-- Most merchants want either a declined transaction (possibly with explanation -- possibly), or an accepted one with a guarantee against chargebacks.

Well in fact their is an issue of misaligned incentives here. Your chargeback insurance has a strong incentive not to receive any chargeback (of course), so they will be overly cautious and decline a lot of valid charges. Stripe on the other hand as perfectly aligned incentives with the merchant, as they don't make money on a blocked transaction.

(disclaimer: I work at Stripe)

I'm no expert here but current job duration may be counter-intuitive. We usually think that the longer the better but it may also correlate with inability to find another job, so in fact during a recession, these kinds of people may actually be more at risk than people used to job-hop.

It probably needs to be controlled for social class and job type but I think this could explain the phenomenon.

Absolutely. It's crucial for a founder to be able to take a step back and think strategically. Being always under water and completing task after task prevents you from seeing the big picture and taking the big decisions.

It doesn't have to be the case, at least not from my experience managing startup teams. The most usual case I've seen is that you have to let the employee go for performance reasons but you still have a good relationship with him and it's pretty natural to help by a) telling what was wrong and what he could improve in his new job and b) offering help to find a new job/talk to his prospective employers about what he did do right. I would even argue that even the most selfish managers should still proceed that way, since ending a relationship on a (as much as possible) positive note decreases the risk of a lawsuit afterwards.

Very interesting read. What I would add to this framework is the often overlooked "solving one big problem" vs "solving lots of small problems". Most startups try to solve lots of problems, which can be seen by the number of features being developped. This is understandable: in the early days, you keep thinking that "if we had feature X, we would close customer A" and keep on adding more and more features.

In general this doesn't work, because small problems are something we can live with. It's way better to solve one big problem, the one the customer is losing sleep over.

At Local Motion, we noticed that the big customers we closed fast were always companies with one very big problem we could solve (e.g. "my cars are getting stolen") vs lots of small problems (e.g. "software tool for maintenance" + "data reports" + "graphs" + xxx)

That's one of the reasons I like the Node ecosytem: the culture is really about finding the right library and designing clean interfaces so that you can switch when you need to. Having worked with Grails in the past was such a pain in comparison ...

Using 90s technologies with node is not really diversity, it's punishing yourself on purpose ...

If a dev really writes code that blocks the event loop, is not tested and not reviewed, I'm not sure he should work on professional projects ...

Anyway with one nodejs process it's not possible, but you can detect a stuck node and use some load balancing with a cluster of node processes (2 is usually enough), and simply reload a process if it gets stuck (while sending an email to ops of course). You need to use such an architecture to get zero-downtime deployments in any case .

The last point about small libraries versus monolithic framworks really resonnates with me. I always have a hard time understanding why my team should commit to one specific way of doing almost everything, instead of picking the best tool for every job. In my experience, framework code is of a very varying quality, some is good, some is not, some doesn't suit what I want to do.

Or NeDB which solve the same constraints :)

Yep, also missing on what collection sizes benchmarks are performed. If that's on a 1 doc, 10 docs or 10k docs collections the results are going to be very different. With these kidns of results I expect the dataset size to be quite small.

Also benchmarks should be runnable by users :)

This article really resonnates with me, having had to choose between two very interesting jobs. It took me 2 weeks to decide and was a really anxious period, whereas without a choice I would have taken either without a second thought.

Couldn't agree more. Most of the tools I see and try are usually just ways to make coding harder and less joyful. Special mention to IDEs which make everything super slow, provide a huge lt of unnecessary plugins and can't even do editing as well as proven editors such as vim or emacs.