Can't remember where I picked this up, but this has been a good mental model for me for understanding the dimensions of this problem of picking what I should pursue in my career & life. It's a riff on "Good, Cheap, or Fast. Pick two."
* Low Risk
* Low Stress
* High Reward.
Pick two.
It seems less down to choice than personality in terms of which two you personally should choose, but understanding the tradeoffs you're making is a good thing regardless.
To me this seems overly simplified. I'm sure there are other situations. I.e. I'm sure sometimes it's "pick three", "pick one", "you don't get to choose", or even "pick none".
And also, if you get a choice of "pick two", you could also: "pick one, balance the other two", "balance all three", etc.
Finally, high risk seems tied to high stress, as also mentioned in sibling comment [1].
I could see truth in the sentiment that if you're receiving high reward, stress and risk are inversely correlated. e.g. if you're working at FAANG, and not working hard enough to be stressed, you're at risk of being fired. Or you're working hard enough to be stressed and therefor have low risk.
A 40-hour a week job jumped to mind for me when I read this. Steady salary without too much risk (if you have decent job security), but half your waking hours during the week and stress that comes with that.
I think I follow but I'm not sure this is correct. Looks like you're saying that jobs with steady salary and job security are stressful. What would be a less stressful alternative?
A low-stakes job at a startup where the bulk of your compensation is equity maybe? Though that situation probably wouldn't stay low-stress for long, as you'll want to do everything you can to make those stocks valuable...
I'd say something like becoming a plumber satisfies that: it's hard, gross work, but it pays well and absent a breakthrough in robotics, I think has a low risk of disappearing as a career.
this is sincerely ingenious. so simple and yet so meaningful.
for a long time I've dabbled on "low risk + low stress" and the new me is trying to go to the 'high reward' mode but yeah, something is got to give.
I basically went from a government worker to an entrepreneur so basically from one side of the low risk of the spectrum to the other. needless to say ,things have been stressful :)
> Once America became embroiled in World War II, there was great concern that rampant inflation would threaten America's military effort and undermine its domestic economy. The concern was valid, as Americans had witnessed what inflation had done to war-torn Germany, devastating its economy and giving rise to Hitler's regime.
> To combat inflation, the 1942 Stabilization Act was passed. Designed to limit employers' freedom to raise wages and thus to compete on the basis of pay for scarce workers, the actual result of the act was that employers began to offer health benefits as incentives instead.
> Suddenly, employers were in the health insurance business. Because health benefits could be considered part of compensation but did not count as income, workers did not have to pay income tax or payroll taxes on those benefits. [0]
You can also read about this in a 2017 NY Times article [1]
"This is the most important slide in the entire talk. So, if you want to leave after this slide, I will not be offended, because it is all downhill from here."
That part in the talk is about the "Eisenhower Matrix", popularized by Steven Covey in "The 7 Habits of Highly Effective People", on the importance of prioritizing important, non-urgent tasks over urgent, unimportant tasks.
PS If you haven't seen his "Last Lecture", it's also fantastic. I watch it about once a year to re-center myself, and remember to focus on the truly important things in life. https://youtu.be/ji5_MqicxSo
OT, but "Will no one rid me of this turbulent priest?" reminds me of a funny Mitchell and Webb sketch about evil villains using ambiguous phrases when ordering their henchmen to kill someone.
For competing with Discord, it seems like it would benefit from a more robust free offering to compete with Discord. Being able to create a free Discord server is great, and it is incredibly capable for most communities that don't need the fancy perks of Discord Nitro etc.
> The free Discord plan provides virtually all the core functionality of the platform with very few limitations. Free users get unlimited message history, screen sharing, unlimited server storage, up to eight users in a video call, and as many as 5,000 concurrent (i.e., online at the same time) users.
For a lot of small communities that aren't focused around commerce of any kind, Discord's free offering blows Element Matrix Services out the water. It's a non starter. If I could create a server with feature parity to Discord's free server, any new community I'd create I would definitely jump on EMS in a heartbeat, and I'd start trying to recreate communities currently within Discord, to be on EMS.
So like a very normal progression for Discord servers is that some niche sub-community wants to gather, and so they create a free server, and people join and there's all kinds of rich content that gets posted and curated and great discussions and then as it gets bigger, people running the community or people who want to support the community will boost the server with Discord Nitro for additional features like more slots for custom emojis (I can't communicate enough how important of a feature this is to Discord's success, even though it seems like minor window dressing).
That kind of model is what would justify a server starting to shell out money every month for EMS. I would note that Discord's pricing for this kind of level of community is tiered and not a per-user thing. You unlock more features based on how many users are paying for Nitro, going up a tier based on breakpoints of 2/15/30 Nitro Boosts per month. It doesn't cost more to have a tier 3 server if you gain more users. This is a big deal for fostering growth and unseating incumbent social networks (which is what Discord and Slack are).
Just some thoughts. I really want stuff like Element/Matrix to succeed!
> From an enterprise perspective, Excel is so entrenched it would be a 5-10 year effort to port existing spreadsheets to sheets. Practically speaking, most companies wouldn't see the benefit.
And at the end of the day, it would have worse performance than Excel both in calculation speed and _much_ worse UI. One of the reasons Excel is so much better than Sheets is speed. Insurance companies spend hundreds of thousands of dollars a year on actuaries. Even if Excel cost them $500/year/user, it would be easily worth it for actuarial departments.
The hundreds of thousands of dollars a year that insurance companies spend on actuaries is the real reason that no one will ever come off excel. The maths is not very complicated but the lack of source control and testing means each bugfix or added feature introduces another bug to fix next week or feature to add the week after.
No, for many reasons. Workbook calculation performance, advanced, complicated spreadsheet incompatibility, worse UI/keyboard shortcuts, slow UI, different language than VBA for custom functions (It isn't necessarily worse, but it's the same thing as trying to convince a department to switch from language X to Y including rewriting every application that's written in X. Also, every person you've ever hired was familiar with X, and has no experience with Y.)
R/Python/SAS etc. are a much more compelling alternative to Excel than Google Sheets (to say nothing of the actuarial modeling software packages that are used already for more rigorous/complicated problems).
If an insurance company decided to move all of their MS Office users to Google Docs/Sheets etc, my money is on the actuarial department paying for Excel out of their budget without a moment's hesitation.
What are your thoughts about it being the 7th most dreaded language on Stack Overflow's 2020 developer survey? I've never programmed in Ruby, but it seems attractive to me.
I honestly cannot believe that this is a solid metric. I believe the question, or their answers are poorly parsed.
I presume a lot of the dread is really about Rails. And the rest partly hearsay of the slow performance of Ruby.
Rails is, to me, a blessing, but also a terrible framework. It helps to rapidly ship products. Just cobble some gems together in a controller or two, mix a gem or three into your models and you have a demo. A rapid Proof of Concept. But also a product that is practically unmaintainable. I've been doing Rails from its very beginning, solving this (trying to) has been my primary job for over seven years now.
And performance? Yes Ruby is slow. But the speed of the language is unmeasurable in, I daresay, the vast majority of the projects of people who tell you it is too slow.
That legacy mysql setup, this poorly evolved domain model, or that badly integrated external API is almost always the thing making it slow. The ms of Ruby handling that JSON to CSV conversion then is practically unmeasurable.
Rust is not going to speed up those 3000ms spend in that ugly SQL query. Go's multithreading is not going to solve the slow API which you call thrice per minute. And Java is not magically making the tangle of classes, jobs, callbacks, listeners and whatnot dissapear.
Rails is alright. It's just a great scapegoat for bad teams working under impossible deadlines: "Our code is unmaintainable because Rails! We need 1 year to rewrite it in Go/Elixir/Java". I mean, because Rails has a flat structure you couldn't ever take the time to reactor that piece of crap code you wrote for 2 years? really? You didn't notice a model stopped making sense or growing in complexity?
I see the same criticism with PHP. It's perfectly fine, stop blaming the tool.
Rails doesn't help you form a proper domain model. Or force you to put side-effects in the proper place; it doesn't help with evolving a proper data model, or avoid tight coupling in unwanted places, it has hardly any tooling in place to employ design patterns.
On contrary: often it encourages bad practices through "defacto" standard gems, or by making "the wrong choice" easier than "the proper design pattern". A "concern" is a simple way to turn a 800-lines controller into four 300 lines modules that amount to the same ball-of-mud, for example. (Concerns have great use-cases, but most often it is not the solution to your problem). Rails offers things like `try(:foo)` to quickly solve that equivalent of the "null-pointer"- exception, without forcing the developers to dive and in and solve the reason why it is nil, or solve it with some design pattern (adapters, null-pattern etc) either: just keep sprinkling `try()` keeps it rattling along too. Somewhat.
So, yes: lack of proper design and architecture is the real problem behind those "ball-of-mud" rails projects.
But Rails' lack of training-wheels and the ease at which to make the wrong choices, really doesn't help teams aim at proper design and archicture either.
> Rails doesn't help you form a proper domain model. Or force you to put side-effects in the proper place; it doesn't help with evolving a proper data model, or avoid tight coupling in unwanted places, it has hardly any tooling in place to employ design patterns.
I think this is only half true. Rails certainly forces very little on you - but has lots of documentation and helping hands pushing you towards tdd - and it has fairly powerful and simple tools to help with data modeling - as long as your data can fit reasonably in the ActiveRecord pattern.
More complex subsystems can be split out into rails engines or services.
All that said,it is indeed easy, without some discipline, to roll out complected controllers and views.
But I don't think it's fair to say that rails the framework via structure or its official guides, encourages that.
Quite the opposite.
As for "try" (now for a long time largely subsumed by ruby's built in &-operator) - that can be helpful where appropriate, like with handling input,and occasionally with explicitly optional relationships and nullable values. But of course NULLs should normally be avoided, and the database should be leveraged to ensure data integrity. And rails allow you to do that.
Rails has a flat structure, it has no knowledge how big your project will become. For many, many code bases this is good enough. Look at Gitlab, which is quite big.
If you need more structure there are many design patterns you can follow and introduce into your codebase.
I like their UI just fine. Speed, smoothness, never had much of a problem. And the amounts of features they were able to come up with the last few years is pretty impressive.
In terms of features I quite like GitLab as well. I just think it's time they rewrote it in something much faster than Rails.
I have literally never used a fast GitLab instance. Anecdotal evidence, I am aware. I'd still venture out to claim this says something about the average speed of your average GitLab installation though.
Hmm don't see any rewrite in their cards though...they're pretty much gonna ride this thing with Ruby. If Shopify did it with their monster scale I bet they can as well.
On the nulls bit, in a context where nil is a legitimate value, my team's policy is to use the ampersand operator. To be honest this is preferable because it clutters up code the least. I don't think we use a single try() anywhere, even before I used ampersands it was always `blah_blah unless x.nil?` etc etc
There are legitimate cases for `nil`, but far less than most people allow.
What does "user.last_login_at == nil" mean? `NoMethodError `to_human_date` for `nil` in email.erb. "Quick! lets fix that with a `try(:last_login_at, "Never")`: if nil, it means the user never logged in.
You now, without proper thought, you introduced a business meaning to a missing value. Adding tight coupling, slowly painting yourself in a corner. How does this translate to "Could you give me a CSV with all users that never logged in"?
Maybe you did mean to assign such domain-meaning to "last_login_at == nil", but then it is far better to explicitely do this. E.g. a `NeverLoggedInUser` subclass, a method on the model `never_logged_in?` an explicit flag in the database, or maybe even a special table "inactive_users" that holds these. All depending on domain-meanings, discussions, use-cases and thought. This is always a lot more work than just throwing another `try` at the bug. Rails "rewards" the bad choice, and somewhat opposes the proper solution.
Rails makes it easy to prototype and rapidly move forward: those are good features. But often you should, instead, be forced to halt for a second. To push you towards the whiteboard. Being able to throw in a quick `try` here, or a `sort(last_logged_in: :desc)` with another `where.not(last_logged_in: nil)` there, and so on, are a blessing when quickly moving forward. But they will haunt you in the future.
Balancing that is hard, regardless of framework, but Rails' features balance towards the "moving fast" a bit too often in my liking. Esp. because it rewards that team-member who "Gets stuff done" by abusing those "quickfixes", while leaving the project with ever more technical debt etc.
Having worked and working with rails projects spanning ruby 1.9 through 2.4 and rails 3.2, 4.1, 4.2 and 5.2 - the major issue I've seen with legacy rails is how difficult it is to keep views refactored and seperateted into widgets. Some teams seem to blame erb for this and run towards various different template dsls like haml (equivalent to writing a template language for php, which already is a template language, because the team can't keep views/templates simple).
Fat/smart models help - but the old/standard tools in rails (helpers and partials) INMHO is poor tooling for the "view" layer - and this just gets worse with Javascript in the mix.
Another option is of course to just use rails as an api server, and do the front end in react/vue etc. Although, at that point, you might be better off just using postgraphile or hasura.
The other real problem I see in some of our projects, is developers simply not trying to learn minimal best practices (just reading a few paragraphs on rails guides...). And that leads to many awkward choices, a lot of re-inventing subsystems that already exist in rails (because developers didn't have a look before coding up a quick fix) - and few tests and poor testability. But those strike me as much more cases of people "holding it wrong" than rails being the problem.
Finally, I think there's still some issues in rails 6 with asset handling - but overall rails 6 seems like a comprehensive, solid and easy to use framework.
> But those strike me as much more cases of people "holding it wrong" than rails being the problem.
My idea exactly.
To stretch that analogy: Rails has guides, books and neat API documentation explaining how you should "hold it properly" (and when not to etc.). But it also lacks "notches", "crossbeams" or "ridges" that help people "hold it properly" on a daily basis.
Well, what you said would be true if management was sympathetic to the argument of "the language and framework we are using no longer serves the project well, so let's rewrite". Since they are not, projects are, 99% of the time, stuck with their first choice of language / framework for life.
What I meant was you can take a messy Rails monolith and do a million things to improve it (including breaking it into smaller independent services if that's your thing). Rewriting in another language is the last thing I would do if the project is big.
Ruby isn't new or novel anymore, and is a relatively small niche. Learning it properly takes time and effort - hence the "dread". I'm pretty sure 10 years ago no one dreaded Ruby yet the language was almost identical to what it is now. So I think it speaks less about languages per se and more about hype cycles and job markets.
There's a saying that Ruby gives "Every toddler a chainsaw" (https://codefol.io/posts/ruby-python-and-freedom/). You can use it and it's metaprogramming to write some really elegant APIs. You can also write entirely the wrong abstractions, and it will not stop you. You can even extract private variables from lambdas if you're willing.
Now, imagine that in the hands of someone with poor taste, or, even, just rather different taste than yours.
Not a big fan of Ruby (okay, with 3.0 I might become a fan again!) but to be fair, these SO surveys are asking really weird questions that appeal much more to emotion than to reason.
It seems less down to choice than personality in terms of which two you personally should choose, but understanding the tradeoffs you're making is a good thing regardless.