Neat.
Would have a comment/feature request for the backlog after playing with the demo:
I will be uld have expected autosuggest behavior in both the frontend search as well as in various admin input fields and actually waited for suggestions to appear before realizing this isn't in there yet.
We ingest a lot of time series (IoT) data and use Postgres for other data so Timescale works quite well for us.
One thing Timescale treats as second class citizen though is updates to existing data points which are 1-2 areas of magnitude slower than inserts. Granted this is also the case for all other TSDB solutions out there which are for obvious reasons optimized for inserts and reads aggregated along the time dimension.
Still would be amazing if you could add to the already existing differentiation of allowing fast updates for cases like ours where we dont store events relating to a singular point in time but rather time-spans so new incoming data points might be "merged" into existing time-spans.
One less mentioned point might be that wework, among other things, sells "hippness to corporates". At least here in Berlin there are multiple extrapreneur gigs (startups composed of corporate employees funded by the corporate) rented into wework. I assume this breath-of-startuppyness is sold for more than the already usual high rates.
We use OKRs on a team level with the teams of 6-8 people being cross-functional. So the Android and the API persons would have the same OKRs working towards to.
They are paying to play -that's how outsourcing works. The high salary of Google devs is priced into the contracts the pentagon pays.
So it's not an issue of salary level but of their inability to build up an internal structure (to which their public image among the SV crowd contributes) which causes them problems.
Can this be solved? Maybe, but not simply by raising salaries.
Very tue.
Coming back to OP, long before this point would have been reached, you might have switched to a different process (probably including VCS setup). But as OP states: many of us are not Bank of America
Generell agree with the sentiment and also the specific case here.
One thing to note though is that a lot of the complexity of setting up Webpack correctly for a standard user is the very high and contradicting amount of SO/Google advice. This is caused by the (relatively) long history of Webpack and the major version jumps.
A layer on top doesn't carry this baggage so may indeed reduce complexity.
Let's rephrase: the real work happens in the office, but during informal meetings many underlying motives and decision drivers become visible, so such times allow a deep insight into how a business works
He downloaded the source code, not the database, so no user data.
Still questionable to some degree, one could demonstrate the problem without a full download
This does disalign goals of the user (get stuff done) and service provider (more money if someone fails as long as he is successful enough not to churn) though
Living in Germany: In most high-pricing restaurant situations I experience the person making the payment for the group would briefly before the last drinks are empty, approach the waiter/bar and make the payment away from the table. Also to avoid debates such as "let me pay, no let me pay, no you can't etc etc"
Personally not so much in model code, but in typescript interfaces/DTO which are used by both routing-controllers on the server side (additionally generating swagger api docs along the way) and by mobx on the frontend.
These kind of articles by one of the compared parties only become interesting once the other party responds. So waiting for Paul Dix to show up in this thread as usual.
Definitely a nice article.
Somehow I would in a real case be hard pressed to distinguish Tutorial and How To.
When teaching a child how to cook, I would do so by showing/helping to cook a simple meal. This would be done in a series of steps. Very much like the definition of howto in the article.