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 :)

NeDB creator here. I'd like to know more about the issue you're describing, I've never heard about it and considering the test coverage I just don't see how it could happen.

Could you post an issue on https://github.com/louischatriot/nedb with your environment details and how to reproduce this?

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.

Interesting read, explains well why I don't like to code in Java anymore. Most Java devs who go too deep in frameworks and complexity should try to build a small project in a very dynamic and concise tech. I always recommend Node.js for that, since you have to selcet the right module for every job, have to think it through and really understand what's going on, and can easily step inside the code if need be.

I really dislike the line drawn between "collecting data on American people" vs non-American people. So it would be ok to spy on Europe but not the US? Come on ...

Totally agree, dark mail feels too threatening.

Another rant by a programmer who clearly doesn't understand JS... It does have its drawbacks (what language doens't?) but if you have some coding discipline you can code pretty big application without headbanging.

So hard to read. Also, do we really need another modelling language? UML was not enough?

(not saying ML could be used to do that, more like "didn't we learn with UML that these kind of stuff brings pain and no benefits")

So many negative comments so let's say it loudly: this freaking rocks. Massive kudos to the team.

Maybe the performance is not yet on par with C. Maybe it will never be. But using JS means we can use this for very rapid prototyping and move on to C when we do need the performance.

The people complaining about performance are the same ones who build very fast and scalable products that nobody uses.

And about JS, let's remember there are two types of programming languages: the ones which everyone complains about, and the ones nobody uses.

You misunderstand me, I'm talking about explaining how your startup works and what the business is. The startup mechanics I'm talking about is the way we generally work in startups, for example the fact that if you work for a post series A startup you have to expect quite some dilution before na exit.

I totally agree. I'll add that Joe should first ask his friends working at tech jobs if their companies are hiring. "this candidate is respected by someone we employ and know is good" is actually the most important criteria for the decision maker. I was hired that way.

That's actually a pretty good idea (and I am being serious). These firms are always looking for good engineers (I didn't say "experienced") and have a hard time finding ones. This is especially true for smaller companies that don't have very strict hiring process.

If a guy walks in my company's lobby to ask if we are looking for engineers, I'll certainly give him an interview.

I don't think it's the job of a startup CEO to explain startup mechanics to his staff.

The article says it makes 100% sense from a business perspective to settle. That's not true, at least not in a collective way, where we should fight to make these scumbags disappear. It's a situation where the personal and the collective are at odd.

That's a great idea, I'll definitely try!

Definitely, spending time validating email is useless. Look for an @ to make sure the user didn't mistake the email field for the name field and send him a confirmation email if you really want to be sure.

You don't seem to know a lot about node. The whole philosophy is "small modules that do one thing well and get out of the way for the rest". If what you like are big frameworks that handle these kinds of things for you, e.g. Rails, Grails, Django ...

Don't pick on Node for not doing something it was not created to do, and will never do.

Nothing new under the sun. The 404 trick is useful but usually it makes the code more readable to handle errors in your request handlers. That way you don't have to jump between the error handler and the request handler.