4 ms·
Here are my rules for picking framework/languages: - Avoid if specifically mentions big companies as users: Facebook, Twitter, Google, these have as many devs
by oxplot 5y ago
Here are my rules for picking framework/languages:
- Avoid if specifically mentions big companies as users: Facebook, Twitter, Google, these have as many devs as needed to throw at the most trivial tasks, and then some. I am in a team of 3 that need to get shit done, not chase package manager and compiler throw-ups. Tell me your language is used by a one person show to serve millions of people and then I'll listen.
- Avoid if the developer base is mostly young people: They are energetic and they don't mind complicating the shit out of something, because they can figure it out now and probably down the road. I'm old, and I just want things to work and I want to understand how it all works without spending a week and wrestling with tooling. Not all out-of-college folks are the same but most are (and I used to be one, so there).
- Avoid kitchen sinks: borrowing ideas sparingly is fine - throwing in every new feature in another language you come across makes for a soup, not a tool. A good heuristics is the rate at which features are added. Look for logarithmic trend.
- travisgriggs 5y agoWould you be willing to share some of the languages/frameworks that have made the cut or washed out for you based on the rubric you’ve given. I’m honestly curious.
- oxplot 5y agoI specifically avoided mentioning examples as that'll stir up a lang-war.
- ZephyrBlu 5y agoYour rules are so vague that I have no idea which languages/frameworks would qualify and which ones wouldn't. Does React specifically mention big companies, have a young developer base and is a "kitchen sink"? I have no idea. Is Python a "bad" language? What about Go? C++ kind of seems like a kitchen sink, is it "bad"? I really have no idea how to figure out if these rules apply to any languages/frameworks.
- krageon 5y agoThe point is you cannot speak to these specifics because it is inciting a flamewar (and also not useful).
- voiper1 5y agoSimilar, but not exactly the same: I've come to appreciate that the bleeding-edge really means you'll bleed over it. In the search for "magic" to make my job easier, it often falls apart of the edge cases. So to just get stuff done, I'll trend towards lower-level software even if it means more boilerplate. Also, there's a great idea that seems very worthwhile. I don't recall the source or exact phrasing: you only have 1 innovation point for a project. Everything in your stack should be familiar to you (and you know the pros, cons, and issues) but you're allowed ONE new magic/helper/tool. That limits the blast radius of all this new-fangled stuff and gives you room to try out new tools.
- oxplot 5y ago> I'll trend towards lower-level software even if it means more boilerplate This is exactly what 90%+ of people working on frameworks/languages don't get. Somewhere in their education/career they learnt that repetition is bad. DRY everything. And then they follow that religiously. Pragmalism (minimal pragmatism) is sorely missing.
- xhevahir 5y agoSounds like this blog post: https://mcfunley.com/choose-boring-technology https://mcfunley.com/choose-boring-technology
- qbasic_forever 5y agoGoogle uses a ton of Java internally. Microsoft uses C# and .NET (obviously). Facebook uses PHP and C++. Are you really avoiding all those tech stacks? They're old, bulletproof, and nobody ever got fired for picking them as choices. Just because big companies use them doesn't mean they have to complicated or trendy.
- rlt 5y agoSerious "get off my lawn" vibes. These might be ok heuristics, but it's pretty limiting to not use some tech just because a big company uses it.
- oxplot 5y agoYes, heuristics.
- rtpg 5y agoMy rules: - Does it work? - Can it be explained to coworkers/usable? - Does it solve the problems I'm having? - Does it seem like it's going to be around in the next 5 years (weaker version: do I need to worry about it being around in the next 5 years?) - Can I debug issues with it relatively easily? Turns out that good rules of thumbs are ones that look at stuff on the merits, instead of trying to find catchy third-order effects that you see in projects that rub you the wrong way.
- msh 5y agoAnother thing, never be the biggest users of a framework. Then you will encounter all the edge cases. Let others find/fix it first.
- Uehreka 5y agoOK, so don’t use a tool/framework that companies bigger than you are using, but also don’t be the biggest user of a given tool/framework, got it. (Edit: For the record I think msh is the correct one, it’s GP’s reasoning that is bananas)
- deleted 5y ago[deleted]
- deleted 5y ago[deleted]