$700 per month. Those are rookie numbers. Come to the UK where childcare is £2k per month.

The UK system gives mediocre benefits and also penalises you if one of you makes >100k a year.

As one of the contributors, I'm always happy to see interest and people using it.

Keeper is a really interesting challenge and we're really open to any kind of feedback and thoughts.

If you tried it out and have some feedback for it, I encourage you to create an issue (https://github.com/ClickHouse/ClickHouse), ask on our Slack, ping me directly on Slack... (just don't call me on my phone)

And don't forget that it's completely open-source like ClickHouse so contributors are more than welcome.

No no no no no.

Design your product to be understandable at first pass. Apple famously doesn't do any of this with your iPhone, while Sony forces you to do it on every new device.

Let the onboarding be a forcing function for usability. This isn't a crutch, it's something worse and damaging.

Amplitude is a great product. We tested alot of similar products and Amplitude was by far the best. The only negative I have found is their pricing which is free up to quite a generous level to be honest but then it suddenly becomes really expensive.

This whole trail through to the top comment is spot on.

It's also helped me work out a corollary in my mind that has puzzled me for a bit.

My sense, in the Marxist tradition, is that modern organisations are dependent on the extraction of value from highly capable technical resources and, especially outside the tech bubble, they largely resent this dependency.

Let's say developers are an example of a highly capable technical resource, though I am by no means limiting the scope.

This results in a series of mechanics that lead to developers being alienated:

  - From the product of their development (ownership of IP and the resultant value of their code, distance from seeing the positive impacts of their work or talking to those it helps)
  - From the act of developing itself (by its reduction to commercial use and control over how it is done, approval gates, arbitrary coding standards, ticket systems, scrum processes, project managers and product owners, Jira, timesheets etc.)
  - From their fellow workers (stack ranking, power dynamics, labour competition, structural organisational tension)
  - From their human nature and natural talent (by the reduction of their humanity and passion and capability to a mere "developer" or "engineer", use of stereotypes, reduction of humanity to output/LOC/story points delivered, corporate gaslighting at questioning this state of affairs etc.)

And most non-developer people that have worked in an average organisation and spent much time with developers have seen all of this at play, and heard how much developers hate it. Yet many still refuse, even in the face of self-interest (e.g. faster delivery of outcomes for a non-technical manager), to empathise and accept the reality of the experience enough to support better workplaces for developers. A tangible recent example is the insistence with all sorts of reasons on getting developers back into the office where they can be watched despite demonstrably lower productivity and engagement.

My sense of this is that what developers can bring to the modern world is the closest humanity has got to magic. And this dependency is resented. And this resentment leads to workplaces in which this resentment is externalised in the form of debasement (e.g. caricatures and other forms of ego compensation - "they're just the boffins, they don't have people skills!"), control ("the boffins can't really be trusted - better add some process and oversight, and given they don't have the people skills better make sure they aren't anywhere near management/clients!"), and dependency inversion ("sure the boffins can do their coding stuff, but they'd be nothing without us to help babysit and organise things, they don't get the way the world works, clearly it's they who actually need us!"). And this environment in turn leads developers to internalise this systemic resentment as a resentment of themselves, their capability, and their work, aka burnout.

But one question has been bubbling away for me for a while.

How do so many organisations arrive at a system in which it's almost a badge of honour to not be one of the doers? That those who can't do, should, as a moral claim, oversee, and manage, and lead? And we should keep adding more of those people until the doers can't possible do. Even when that produces lower tangible results.

Maybe at one point I internalised the Office Space / IT Crowd idea - the non-doers are "people people" who didn't spend decades at their PCs honing their craft but instead went to wild parties and focused on normal people stuff (the implication of course being that developers are lesser than normal people). Maybe the developers really can't be trusted. Maybe they do need to be managed and watched and distanced. Maybe the code monkey caricature (before being reclaimed by those it was used to demean) is right.

But now I wonder.

What if those people are empowered by the systems into positions of power over developers because in the first instance they affirm the original resentment: what if putting non-doers in charge safely perpetuates the idea that the developers belong at the bottom of the pyramid and affirms the extraction of their labour in support of the salaries and profits of those above relying on it? Or to put it another way, what if the code monkey caricature is effectively a justification of Marxist exploitation?

And what if the second order effect here is that some, let's call them the senior management class - leaders of the Second order of Pournelle's Iron Law of Bureaucracy in the example above - are more conscious of these dynamics and consciously perpetuating them. What if they are knowingly hiring more non-doers to help keep this balance and control. What if it's not accidental, or people skills, that means non-doers are in charge? What if the very reason they're there in the first place is to be in charge even in positions outside of formal leadership (or at least indirectly support the power of someone else who brought them in for that reason) - after all they're not there to do.

So to close out a long post, a corollary to Pournelle's Iron Law of Bureaucracy: in any bureaucratic organisation the ability to be able to contribute to the goals of the organisation will be an insurmountable barrier to having influence or control within it.

Why recommend lock-in vendors when there are better options in between? There was no mention of Heroku which is easy and scalable.

Hugo is wonderful, until a deployment bug or misconfiguration exposes all of your server settings in a page that should be serving a 404 instead. Wordpress, Hugo and others also get constant attacks from hackers who can exploit each bug found on thousands of sites all at once.

Go has fantastic server examples and plenty of starter templates you can use to build your own server, and deploy to Heroku and scale to millions of users far cheaper in engineering and financial terms.

My free PR advice to companies announcing layoffs is to cut short on the cute company employee nicknames, keep the 'Twilions', 'stripes' and 'Zoomies' to the good times.