My own personal experience, but my 80 year old FIL changed a lot after he started going to dance classes. He was always in decent physical health, but prior to the classes he was a very stressed, unhappy, solitary type of person. Since then he's become much more extroverted, social, and generally happier.
Obviously I think the benefits are more than just the dancing itself, such as the community, but even when you ask him directly about what he thinks caused the change he points to dance classes.
Senior Engineer tends to be a catch-all phrase for people who have 3+ years of experience but, for whatever reason, are getting into the next level of promotions (Staff for IC/TLs, manager for EMs). Most people are in this group, and there's nothing wrong with being here.
I wont go into detail about what it is (since the docs are good enough) but in short, it's a feature to let you setup multiple TypeScript projects in the same repo.
Some things that project references will solve:
- importing test files from your impl files will throw an error
- you can specify what types are available. for example you shouldn't be able to use `@types/node` in your frontend code or the `DOM` type in your test code (or vice-versa)
- no type checking the whole repository again just because you changed the test.
I think there's quite some control over how strict you can be when you say you're using TypeScript. Project references is another way of making your config more robust, and it may not be necessary depending on your needs (like when some people disable strict:true). I think it's a better choice and relying on a properly configured project shouldn't be a issue for users who are actually going to use this (who are likely maintainers of their project)
I'm spending the summer in Canada, where they invest a lot in third spaces, and the difference between Canada and the US in this regard is night and day.
- Parks: A lot of them, every few blocks there's a large, well maintained park. Trash cans everywhere.
- Many community centers, huge, filled with extremely inexpensive or free activities. Community centers all have gyms in them.
- Beautiful, modern feeling libraries
It's hard to describe the difference, but it is non trivial.
I'm in the US. I've spent time visiting in Canada recently as well.
Everything in your list is stuff I experienced in most of the parts of Canada I visited. Not all though, for instance it wasn't like that in the parts of Mississauga I visited. And everything in your list is stuff I experience regularly in the US, in the parts I've lived in.
Have you used vercel before? It's a lot more than just a layer on AWS. They really understand specifically what Front end engineers need to be productive with their external stakeholders (ie: design, product, etc). I'm sure other products do this now but they were, as far as I know, the first to automatically deploy a version of your app by PR, for example.
Can you do this yourself? Yeah, obviously. But it's a build vs buy conversation and for a lot of people the value that this tooling gives you immediately is worth the buy.
I am a fan of the dev branch strategy [1], where I have a specific commit that holds all my customizations that I rebase off of. This blog post has it set up such that git automatically ignore pushing the dev commit, but I haven't really gotten that far yet. I just rebase my branch off current main when I'm ready to push.
I use Jiujitsu, and my personal experience is that the basic "write code, git add what specifically I want to history" flow is the same. The working commit is the effective staging area and it doesn't get forever committed to public history. Without going too much in detail, the working commit can't be pushed to your remote, similar to how the staging area can't be pushed.
Your currently active commit is the staging area, only now that it's a "real" commit instead of some bastard half-commit all of your regular tools work with it directly. Same goes with the stash, it's rendered completely irrelevant.
When you're ready to "commit", you give a description to your current set of changes (`jj describe -m`) and then split out any of the pieces you don't want into the next commit (`jj split`). You get to pick the parts you want pulled out, and those get pulled out onto a new, fresh commit.
There's a notion of "empty commits" (commits without messages) in JJ. These are basically the "staging area" of git, and if you try to `jj git push` it JJ will reject. So these commits cannot make it to the remote branch.
To be honest, JJ makes it way easier for me to craft clean commits. The design philosophy of JJ is commit-oriented, not branch-oriented. Since it's a frontend to git, everything it does is fundamentally git. But it allows commit-oriented workflows to flow so much easier than git does.
Obviously I think the benefits are more than just the dancing itself, such as the community, but even when you ask him directly about what he thinks caused the change he points to dance classes.