I've always wondered if there is a business opportunity here: a company that monitors social media for all mentions of your business and pings you about it. Maybe this already exists?
1,207 karma · joined November 23, 2012
This is an interesting thread, but my advice is to never take comments on the internet as any sort of representative sample. It is unlikely someone happy with their job would comment on a thread about quitting, because it makes for a boring addition to the thread.
I sometimes wonder what my work life would be like if I switched back to mechanical engineering, but I'm very happy working purely in software. Engineering requires a ton of capital and fairly large teams to do cool things. With software, a single person or a small team on a shoestring budget can build pretty neat things. I also work 100% remote, which I'm not sure would be possible with a mech eng job.
I do wish I spent more time in the machine shop at school though. Many of my neighbors in my HOA are either "real engineers" or retired blue collar workers, and they can fix things much better than I can. I can help reset their router though! :)
Feeling a few earthquakes a day has been an interesting experience. It has been going on for days now, and quite a few people are on edge. I tend to think a lot of smaller earthquakes are better then one large one, and all of these earthquakes release potential energy that could have been released in a larger event.
I'm sure we'll be fine, but I hope those aren't famous last words!
We recently moved our data warehouse to Snowflake. Along the way, we adopted an ELT paradigm instead of ETL, where you load your raw data into the warehouse and then perform any transformations in the warehouse. A tool called dbt (https://www.getdbt.com/) has made this a joy. You write SQL select queries in SQL files, and dbt creates a DAG based on this SQL so it can efficiently create tables/views in parallel. dbt also comes with some nifty testing facilities to validate your data once it is transformed.
This is a great article, thank you for writing it!
This is a well-written article in which the author lays out their thought process for optimizing a slow SQL query. The article certainly provides more value to someone who may not be an RDBMS expert than your comment does.
I am pretty sure we could live comfortably on a db.r4.4xlarge, but we have some bursty analytics applications that sometimes bring our load up for about a minute, and we like the peace of mind of headroom during peak hours (we are in edtech with super predictable traffic throughout US school hours).
Total side note: I just went to the pricing page and it looks like they just released db.r5 instances for Aurora (https://aws.amazon.com/rds/aurora/pricing/)! It might be time to try those out. I don't see an announcement just yet though...
> Among the theoretical contributions of the early years of the Austrian School are the subjective theory of value, marginalism in price theory and the formulation of the economic calculation problem, each of which has become an accepted part of mainstream economics.
Hayek was considered partly Austrian and he got the Nobel Prize in Economics in 1974, well after this book was written. (https://en.wikipedia.org/wiki/Friedrich_Hayek)
The core lesson of the book is fantastic:
> The art of economics consists in looking not merely at the immediate but at the longer effects of any act or policy; it consists in tracing the consequences of that policy not merely for one group but for all groups.
This is not fringe at all.
Can you expand on that? How does no parens make it harder to pass around first class functions? In Gluon (and in Haskell, Purecsript, Idris, etc), you just pass around the function name. If you have "inc x = 1 + x" and you want to pass that to map, you just pass it by name: "map inc [1, 2, 3]"
What could be simpler?
Another cool feature of Gluon is modules are basically just records. This is a strict improvement over ML modules in my opinion. (See http://gluon-lang.org/book/modules.html)
Congrats on the recent release!
Modern macroeconomics comes off as such a tribal, groupthink discipline to me. Far too many policy suggestions stem from tortured analogies like "we need to prime the pump and increase spending to increase aggregate demand!", or "Capitalism runs on sales, ... you have to increase spending to increase sales!" Where is the analysis of the real cost of programs like this? Why are we so focused on short-term results without considering the long-term effects?
Economics is not physics. You can't run controlled experiments and discover mathematical relations that succinctly describe entire economies. I wish we would stop taking the poor excuse of what is currently macroeconomics research, which is basically terrible curve fitting on small sample sizes over a brief historical period sprinkled with whatever ideology the economist subscribes to, and jumping to terrible policy decisions that affect real people.
Warning: a lot of the literature and talks on ES/CQRS get bogged down in Object Oriented and Enterprise minutia, and detract from the promising core ideas. My advice is to try and see the forest from the trees when Googling these topics.
Now, I'm not some heartless jerk who doesn't recognize that the short-term effects of job loss on unskilled workers. It is certainly a hard problem, but I'm still not convinced that we will have some epic labor shortage because all unskilled jobs will vanish too quickly.
Interesting, I think the entire industrial revolution is a very strong counter example to that statement. We repeatedly automated the majority of jobs on the planet every few decades and we saw the largest expansion of wealth and prosperity for the majority of humans in all of history. Should we lament over those subsistence farming jobs that were automated away?
The free market isn't some singular entity that figures out problems before they arrive and sends us all an executive summary of its plan. We currently don't have mass unemployment from automation, and I don't agree with many of the reasons people express for worrying. The only arguments I've seen against mass automation are hints of some dystopian future where somehow robots are prohibitively expensive for all but the richest people, and goods will somehow be cheap enough from automation that non-automated manufacturing can't compete, but still expensive enough that if we don't work 40 hours a week we'll starve.
Sure they do, with a proper library. Haskell's persistent library does this very well.
I don't use Rust, but your code examples look great! I understand that Rust has less opportunity for "magic" to clean things up (for example, in Python you can use a decorator to specify a route for a function), but otherwise it looks very clear. Awesome work!
That's a pretty neat feature!