Honest question: why would I want a distributed scale-out RDBMS based on SQLite when there are others based on more performant server-based solutions (see Citus for PostgreSQL, Galera for MySQL, etc)
My understanding/recollection of SQLite is that it has significant performance issues with high concurrency. Great for a database on a pocket device, not the best choice for a horizontal scale-out high-concurrency system. At what point do I need horizontal scalability, but not care about concurrency on any one node?
Again, honest question - I'm not doubting the project or its value, I just don't get it.
I think you're misunderstanding the goals of the project. It's not to create a horizontally scalable DB. Write perflrmance will not scale horizontally at all with this database.
The goal is to create something more like an etcd that can hold structured data.
rqlite gives you the functionality of a rock solid, fault-tolerant, replicated relational database, but with very easy installation, deployment, and operation. With it you've got a lightweight and reliable distributed relational data store. Think etcd or Consul, but with relational data modelling also available.
You could use rqlite as part of a larger system, as a central store for some critical relational data, without having to run a heavier solution like MySQL.
Performance
rqlite replicates SQLite for fault-tolerance. It does not replicate it for performance. In fact performance is reduced somewhat due to the network round-trips.
First, let's talk about your assertion - we're basically all just in this for the money. If you want to make that claim, you have to be able to answer why. Why is money important? Why would we do anything just for money? Money itself is irrelevant, we only want it because of what we can get with it. So, let's go a step further and figure out what we'll buy with that money. Sure, you're going to buy things for yourself - most people likely will. But are they going to spend it all on themselves? Most likely not. Many people will spend that on gifts for their spouse, a vacation for their family, school for their children, a new house or car to improve the lifestyle of their loved ones. All of these things are honest reasons we justify spending our lives working - to improve not just our own life, but the lives of those we love (and for many great people in the world - the lives of people they've never met).
Second, let's go towards your statement that people just can't have a deep passion for things. You're saying that people can't do something because they're particularly interested in or dedicated to a particular issue? Ok, explain Doctors Without Borders, the Boys & Girls Club of America, St. Jude Children's Hospital, or literally any other charitable organization in the world. Are its founders, low-paid employees (relative to market potential), and unpaid volunteers just in this for the money also?
I'm keeping my cool here on this, because ultimately this is a comment and we're all free to express our minds - but I'm offended by the assertion that we can't care about anything other than money. And that's after you get past the fact that the statement on its face doesn't actually make sense, because none of us care about money - we only care about what we can get with it.
Edit: perhaps a bit of an overreaction to otherwise benign comments on behalf of the OP. I still feel strongly about my comments here, but may have misunderstood the intent of OP's statements.
I don't think OP is talking about Doctors without Borders. He's talking about the super hyped engineer at a big Ad company who says she's extremely passionate about her job. This sort of attitude is very common in the U.S., in my experience.
Ok, sure, but the OP didn't qualify his/her statements that 90%+ of us are lying when we say we're anything other than financially motivated. I'm attacking the assertion that we simply can't be intrinsically motivated by things that matter to us.
That said, I do know engineers that work at startups and actually are pumped by the vision - they're excited about what they're building and what it could mean for the future.
"That I need money and this is my best choice. I would guess 90+% of people who say theres anything more to it than this are lying to you and probably themselves."
I'm not sure how I'm misquoting you here - you very clearly and plainly said you assume 90%+ of people who say anything other than money is their motivation are lying to you and themselves.
As for your comment that you need money to live - of course you do. That's a far cry from your statement, which is that people are solely motivated by money. The typical HN reader likely makes above the average salary, so they're already past the point of working for enough of a salary to live, and they're in the disposable income territory.
I said money itself is irrelevant. Saying we work for money is stupid, because we don't. We work for the things money could buy. It's an arguably arbitrary distinction, but in this case it's important, because it speaks to the meaningless first statement of the original post.
How can we all be working solely for money when none of us actually care about the money - we care about all the other things that the money gets us that the original comment explicitly stated we don't care about.
Edit: I think we're on the same page here, but perhaps I could have clarified what I meant in my comment. Money itself is meaningless, as you mentioned, it's a proxy for other things we can get. Which is why it makes no sense to say we're motivated by money. We're motivated by the things we want that money to buy for us.
Agreed. If you look solely at my comment in response to the one I replied to, it probably seems like I missed the mark. However, take it in context with the OP's comments for the topic
"I can see what is going on in my head, that I tend to materialise some image of my future self, create value for the family and the environment I live in, position myself good for the future-needed skills, have joy in what I do, have more freedom to decide of my future direction ... there are many different triggers of motivation for my actions, but from time to time they seem random and misaligned."
In that context, he's clearly referring to (at least to me it seems) deeper motivations that simply financial. So, to have the top comment on this page say 90%+ of us are motivated financially and lying if we say otherwise, in the context of this topic, I think is just wrong.
That said, I've edited my original comment to clarify I may have misunderstood the one I replied to.
he did say "most" and based on my experience with many people in the industry, i have to agree with OP. most folks are in this for the cash (myself included).
why do you think articles on salary and negotiation are so popular here?
For better or worse, SV is home to a lot of incredibly high-risk investments, and a large of early startups.
Startups with a lot of money on the line and no path to revenue will do crazy things that frequently lead to toxic work environments. Raise $10 million for a product that doesn't have a market fit, hire 10 people, provide them no clear vision for your business or product, tell them to make money, and watch as your business gets pulled in 20 different directions, employees fight, and people stress out. It's not likely to end well for anyone.
It's definitely going to be more common in places where riskier investments are more likely to happen. Uber, as an example, was last valued at nearly $70b and loses nearly $800m every quarter. I would imagine that kind of cash burn with no clear path to profitability is incredibly stressful on everyone. It's almost certainly the cause for many of the horrible decisions that seem to have been made there, and the same thing can apply at smaller scales to earlier businesses.
My observation is that this is far more a function of the business' product/market fit than it is the size or age of the business. When you're struggling to pay salaries and bills, and there's no end in sight, often the business (knowingly or not) overworks and stresses their teams to try to make up ground. Unfortunately, the last 3-5 years have seen a lot of very high-risk seed investments in products that seem to have no actual viable path to revenue, which fuels this belief that startups are the problem.
This is not to say startups are without risk; they obviously carry risk. My point is simply that you can absolutely find a startup that will provide you with a reasonable work/life balance. Remember, interviews are as much for your benefit (if not more) than they are for the business. Use the opportunity to ask them about their product, their revenue, their roadmap. You'll probably get a good idea of how hectic things are.
And for any founders/employers out there - respecting the personal lives of your teammates will actually make them far more productive, not less. Aside from just being the right thing to do, it also has the benefit of earning their trust and respect, which will keep them with you.
There's also a difference between holding your customer's hand and building unsustainable expectations. The only expectation you've built by holding their hand through the onboarding process is that you care about your customers and want them to have a great experience. That's exactly the expectation you want your customers to have. Many startups have been incredibly successful at acquiring customers from incumbent businesses with more features and possibly cheaper products, by simply caring more about people.
At the end of the day there are people using your product (presumably). The more those people feel you care about them and their problems, the more likely they are to give you a little space as your business gets off the ground. Maybe they're willing to tolerate a few minutes of downtime, the occasional bug, or missing feature, because they know that they're always going to be treated well by your team.
Cultivating strong customer relationships is a great element in any business, and it's virtually a requirement in modern B2B.
offering to build (tiny! like, 5-minute one-offs!) features _just for them_ sort of blows their minds
It seems worth noting that this can also be a dangerous strategy. It's really easy to fall into the trap of giving each customer exactly what they ask for, rather than learning what they actually need. If gone unchecked, this is the sort of product strategy that easily leads to disastrous results for product usability and experience.
This isn't to say that as a business you're always (or ever) better at knowing what your customers want than the customer is; but you are in a strategic position to be able to understand what similar customers are asking for, and distill that down to the core problem that needs to be solved.
I'm sure this isn't the extent that the original comment was aiming for, but it felt worth expanding on this since the whole topic is about early products getting users. A key component of that is ensuring you're building a product that people want to use.
A mitigation strategy here is to delay implementing any new feature for a single customer, in order to query your other customers as to whether they need the same or similar feature. Oftentimes you will find other customers who are interested, even if their exact needs are slightly different from the first customer's request.
Best case scenario you get to build the feature once, based on a spec that fits the needs of a larger pool of customers. This reduces the overhead of more customers inevitably requesting similar features weeks or months down the line.
Worst case scenario you still wind up releasing a feature that only one customer is going to use. At least you've tried your best to fold more customers' needs into a single unit of work. Better to have asked and found no takers than to have not asked and wound up with repeated requests for similar features once it's too late to combine the work.
> It's really easy to fall into the trap of giving each customer exactly what they ask for ... this is the sort of product strategy that easily leads to disastrous results.
do you know any product/company examples where this was/is the case?
See aianus response for some examples, I would also add:
- Windows Mobile (pre WP8): Customers may have asked for a mobile computer, but most did not actually want a weak version of their computer crammed onto a tiny screen. Apple and Google helpfully showed them what customers actually wanted with iOS and Android.
- Blockbuster: Customers may have asked for a large selection of movies for rent, but they didn't want a physical location they could drive to and browse through. Netflix gave people a new option (multiple new options)
- MySpace: "Customers" may have asked for customized/personalized profiles, but they didn't mean a dumping ground of random html and css that eliminates any sense of uniformity, brand, identity, etc. Facebook gave people the personal touch they actually wanted without compromising the experience.
Now, these are colossal failures, and we can endlessly debate whether you believe these failures were the deciding factor in their respective products. But I think we can probably agree that, at the very least, failure to cater to the actual customer need (instead of what they simply ask for) was a major flaw in all of these cases. And these are just a few examples.
Also, I'm not sure if it was intentional or not, but you cut my quote at an interesting spot. I'm not trying to suggest that a business should not cater to its customers' requests. Rather, that it should not do so at the expense of trying to understand the need behind the request.
I can't name examples, but I've worked for places where this happened, and the results were paralyzing. The only way to do it right is to add each feature as if all your customers were going to use it, but instead, people cut corners and write features in such a way that they only support the targeted customer(s). They compound the problem by adding special cases in the business logic to make sure the feature doesn't affect other customers even though it's broken for them. They add features for one customer that aren't even logically coherent for other customers. They lower their sights from "make this code work for every valid set of inputs" to "make this code work for all of our current customers, except the ones who won't notice because they don't use this feature yet."
The result is completely unmaintainable. You can't change anything because every piece of data has accidentally acquired special meaning.
"You can't remove the dog_shave_preferences column! It's how we distinguish between customers who were added before June 2013 and customers who were added after!"
The work to add a customer whose data doesn't trigger the right special case logic starts to be seen as a "new feature" rather than fixing bugs.
"Hold on, this is a fundamentally new set of requirements! We've never had a customer before who had the Bloop module enabled and had a logo bigger than 5k and wasn't AcmeCorp! We should have been aware of this new requirement before the customer went live."
The trap is how quickly people adapt to this kind of thinking, to the point where normal engineering starts to feel weird to them. I once quite seriously suggested creating a database table to record which customers a certain feature was broken for and had it shot down because people thought the byzantine special-case tests it would have replaced, which had no other purpose, constituted valuable business logic. The ideas and conditions we had invented to track the limitations of our code had started to feel like real business distinctions that they couldn't imagine living without.
Suffice it to say that eventually we slowed down to the point where declaring a feature freeze didn't feel like a drastic change to anyone, including our customers, and embarked on a substantial rewrite. It didn't end well. I've encountered another example that was a lot more sane (people knew they were doing the wrong thing all along and didn't actually start to believe in the reality of the distinctions they wrote into code) but it suffered from the same maintainability problems.
A word processor company named WordPerfect used a similar "feature on demand" idea quite successfully during their early years in the 1980s. They only abandoned it when it got just too unwieldy, but by then they had become the standard word processor for law firms. They eventually got sold for what was then quite a decent sum.
Very good points about avoiding support and customer service traps that you can't back out of. But I think in the context of how to "acquire your first 100 users," trying things that don't scale may be worth the risk. There's limits, I'm sure.
This reinforces the general problem that strings of characters are bad candidates for authentication. Users generally fit into two categories: those who will use the same password for everything, and those who won't. The latter half is the more technically savvy - which means they were likely to take the appropriate steps, read the appropriate news, and protect themselves against most classes of attacks. In short: the people who are likely the most vulnerable are also the ones that are least equipped to do anything about it.
It's a general problem with username/passwords as authentication and I think this is an interesting space for new start ups and service providers. Even with standards like FIDO, companies will want to be able to integrate it easily into their systems. The faster we can just kill passwords, the better.
I'll second this. I have built a lot of ideas and prototypes over the last year or two. I used to spend a lot of time focusing on the architecture design of these things, building in microservices using the latest technology wherever possible. I figured this was the best way to go about it, until the day I realized I was spending 50% of my time trying to set up a distributed microservices environment, 40% of my time fighting with the tools I was trying to use to build my prototype, and 10% of my time actually building my prototype.
This is the biggest problem with trying to scale too early - you take the focus away from your product. The reality is that most businesses will not work out. Instead of focusing on scaling something that may never sell, you should use the tools that allow you to iterate on your product as quickly as possible - where reasonable.
As stated above, if you end up needing to grow the business, all the code will eventually be rewritten. The data, however, will likely be much more expensive to change. Put some time into thinking about your data model, but otherwise focus on building your product.
My understanding/recollection of SQLite is that it has significant performance issues with high concurrency. Great for a database on a pocket device, not the best choice for a horizontal scale-out high-concurrency system. At what point do I need horizontal scalability, but not care about concurrency on any one node?
Again, honest question - I'm not doubting the project or its value, I just don't get it.