I’ve used the git cli exclusively for more than a decade, professionally. I guess it varies wildly by team, but CLIs are the only unambiguous way to communicate instructions, both for humans and computers. That being said, I still don’t mess around with rebase for anything, and I do use a gui diff tool for merge conflict resolution. Practically everything you need to do with git can be done with like 10 commands (I’m actually being generous here, including reset, stash, and tag).

I believe the setting is user.email so maybe confirm that’s what you have set in both? Git will silently ignore settings that aren’t used/defined.

Like I said in my other comment, I think people tend to lump all of MSFT's activities into the same bucket. DevDiv has always seemed pretty decent, and I am usually reminded of this comic when people talk about MSFT's "shady" activities.

Everything is temporary. If we were talking about a niche language, I might worry a little bit that it could just lose momentum and die. But TS is a juggernaut. The only way typescript “dies” is if JS integrates enough of its features to make it redundant.

Besides that, if Oracle managed to allow Java to continue to grow and flourish, I have confidence that MS can do at least that well. I also think lumping all of MS’s products into the same boat is a mistake. They have been pretty good stewards of their languages for decades.

Unicode is thoroughly underrated.

UTF-8, doubly so. One of the amazing/clever things they did was to build off of ASCII as a subset by taking advantage of the extra bit to stay backwards compatible, which is a lesson we should all learn when evolving systems with users (your chances of success are much better if you extend than to rewrite).

On the other hand, having dealt with UTF-7 (a very “special” email encoding), it takes a certain kind of nerd to really appreciate the nuances of encodings.

You might have a look at “CONTRIBUTING.md” files in repos.

• Set quality standards (no giant PRs, follow documented coding style, include tests for changed functionality, etc).
• Establish a way to discuss contributing work before they do it. Generally, have them open an issue discussing the proposed change and get buy-in from the maintainer (you) before starting work.
• document any high-level goals and non-goals in the README.md for the repo, and refer to that when discussing changes. You can always amend it as you discover more about what should be built.

Initially, contributors can fork and send a pull request for you to review and merge. You do not need to give them any write access to the main repository. Be respectful of their time and review PRs promptly.

If multiple people want to collaborate on a branch, they can do that in their fork. In my experience, this is pretty rare, usually you don’t want multiple people committing to the same branch (except for merges to master/main/stable, etc).

If you have a few dedicated contributors that have a history of submitting good quality patches, and alignment with you on your project’s goals, you can invite them to have more control in the main repository, at which point there should be minimal concern about granular controls.

Sure, you can make it 10x faster by optimizing the complexity, but I can improve throughput by 1000x by putting it on 1000 machines.

In practice, it’s a bit of both. Paying attention to Big-O and understanding the gross relative cost of various operations goes a long way, but being able to run an arbitrarily large number of them can get you out of a lot of jams.

This is an professional experience thing.

Types support “programming at scale” - scale in the sense of larger code based or multiple people contributing.

If you’re hacking away at a script for a web page, then yeah, have at it.

If you’re supporting more than a few hundred lines of code or working on a team, you need types to codify and communicate information that can be verified with a compiler.

Whenever you see a larger codebase that is not strongly (or statically) typed, you generally will see unit tests that are verifying the types/structure of outputs.

Yeah, dropping typescript and then codifying type information in jsdoc is comical.

The only thing I would say about your experience is that “dropping TS for go” is a little bit misleading, and it doesn’t really sound like it bears on the general debate of “TS vs. JS” - go and other static languages generally fit a different niche in my opinion, and can be a better option for certain kinds of systems.

If you’re building anything of even moderate complexity, or with more than one person, you really need the types and modularity that TS provides.

I guess it’s also worth noting that JS has actually been influenced/adopted some key features from TS over the years, so it’s possible to do a few things with it to make stuff that’s a bit more maintainable.

This one is a bit tricky, because you have to think about logging as an output or a side-effect. And as an industry, we’ve been learning that we should limit the amount of side-effects that our code generates.

If logging is getting ingested by downstream systems like CloudWatch, or other structured logging systems, it is potentially going to be used to detect service issues and track overall service health. These are logs that are serving a functional purpose that is not purely a side-effect, or for debugging forensics.

If this is the case, then you should have a unit test asserting that a log entry is emitted when a method is called. If writing that test is a low or non-priority, then even if it’s a “breaking change,” then that’s a sign that it’s not actually going to break anyone.

I’m sure there’s some monadic view of how to package up the “side-effect” logging as part of a function’s output, but it’s probably annoying to implement in most languages.

Important/generalized patterns reveal themselves over time. I generally push for people to just write the specific thing they need for the given context and then if the same pattern shows up elsewhere, promote the code to a shared library. It’s really hard to anticipate the correct abstraction right from the start, and it’s easy to include a bunch of “just in case” parameterization that bloats the interface and adds a lot of conceptual overhead.

That being said, with low-leverage/complexity code like html views, repetition isn’t as problematic. Although, I do think that HTML components have matured enough to be the correct unit of abstraction, not CSS classes.

Cue the first post about the exploit that leads to leaking AWS keys. I’ll wait.