- 0 Posts
- 17 Comments
0·5 months agoWe aren’t using
json.atChar(17)to get values?
My plan is to burn out soon, and work on projects for fun/side jobs. Corporate world has absolutely vacuumed my life long passion in the past 5 years.
I honestly and truly don’t want to spend time relearning another system like this, especially one without decades of documentation and support available.
I’m only 65 inches tall. I would want to make some sort of crazy mirror room with them.
It’s not the language that matters, it’s the obligation vs passion.
There’s no parent at all. Maybe a tiny confused baby sea turtle.
They want you to install the app so they cand send you notifications/ads.
Well, for example, there’s no reason eslintrc and eslintignore need to be separate files in any scenario, i would group them and prettier into “formatting”. But, yes I agree, one big file is preferred in most scenarios.
If the picture in the OP is the only alternative, I wouldn’t mind, you can easily collapse json/yaml and only focus on the section you need. Maybe split into files based on functionality.
If they could all coesxist in one file, preferably json or yaml, it would be better.
This was my first time actually seeing a Rust example, and I hate it.
Situation: You’re building some software to display emojis based on user input.
Current code: when user types “happy”, output 🙂
- Your new requirement: when user types “happy”, output 😃 instead of 🙂
- Coworker’s new requirement: when user types “sad”, output 😭
You implement your change, back it up, and the new version with 😀 is released. But it turns out 😃 is the ultimate insult in the Snowflake region, and you need to immediately rollback 😃 back to 🙂 while you find an alternative.
Meanwhile, Coworker has added 😭 to your backup, which still has 😃. Now when you try to rollback to 🙂, Coworker’s code gets erased. Now your code is unable to safely support both 😭 with 🙂 without starting over entirely. Maybe you want to disable 😀 only for the Snowflake region, but that’s not possible either without harding coding the regions instead of just changing the deployment.
Now imagine working with a team of 10 people, or a company with 100 people working on this same software. With features and release dates constantly changing.
Merging conflicts will be an issue no matter what you’re working on. Maintaining different sets of code bases based on the version/release will be an issue even when working alone.
That doesn’t hold up so well when you work with other people on a project.
Ham/ster