Don't know about efficient, but there is at least two ways which seem to work OK-ish (although not all that efficient, I gahter):
* Do regular certifications. Before certification, check if the document is up to date. If not, update it.
* Share the documents to answer teammates' questions. Like with a WIKI it may turn out that the important stuff is actually missing/undocumented/outdated. This is then a good opportunity to fix the document.
I used to work in medical devices where it's all about documentation and even there nobody took the time or had time allocated by management to work on documentation. And most people aren't good at writing so the documents were terrible.
> > a Google Account that isn't tied to anything else.
> Isn't that pretty much impossible? You need a phone number for verification, which effectively ties it to that phone number.
I just want to follow-up on this because some people claim this is not correct because they have managed to create accounts without phone numbers.
Indeed, I think to this day, under special circumstances (like e.g. on reasonably recent Android devices) you might be able to setup a Google account without phone number.
The trick is, that in the general case, you can not keep this account online indefinitely.
First thing to note: This way of account creation does not seem to work anymore.
Second thing to note: After once logging in from a different country, trying to login again REQUIRES me to provide a phone number after successfully giving username/password/2FA code. No way to use the recovery code instead...
Also, given that this account was never before connected to a phone of any kind, by definition, the addition of a phone number cannot provide additional security confirmation (it's data that simply wasn't present before and any "personal" phone number could potentially do -- of course I haven't tried, because that's the point of not linking a phone number).
I think this way it is finally proven that they only do this to harvest the data/phone numbers and any claim of enhanced security is void.
I write this after having lost the second account to the phone number required screen despite being in possession of all the credentials which were ever assigned to that account...
In the Bash shell, true is a builtin. It may be a builtin for other POSIX-compliant shells. false is also a builtin.
The key difference is that : is required to be builtin. There are several good reasons for this. For example, syntax: the shell can single out this special character syntactically before searching $PATH.
Also, ":" is a disallowed or problematic character for certain filesystem types. If your shell attempted to omit this builtin, it could not always rely on an external command file by this name.
Lastly, people keep bringing up fish, but it is not a POSIX shell, so its similarities in syntax and operation are coincidental.
Please continue to blog about the obvious stuff. It happens all of the time that I want to explain to someone what I think is an obvious concept and then I am sometimes surprised to find out that there are no good blogs where I could link to for an explanation...
TL;DR Plenty of ideological opposition which will loudly call you out for any usage of AI, and also quite a few nuanced takes which will no doubt be overridden by the vocal opposition. It got to the point the site itself told me to leave.
I don't feel comfortable posting my projects there anymore, even though they do have meaningful human authorship. Still have my account, but I'm essentially a lurker now. I'll participate if someone else independently posts my stuff there.
Feel free to reach out and introduce yourself if you want an invite.
On Github, there is a way to leave individual comments in the code and in addition give a review a summary.
In addition to hitting the "approve" button, I typically spell it out explicitly in this summary: "Please check my comments and see if anything makes sense to implement."
Often, I also take this opportunity to point out the "one" most valuable change in my opinion.
If the developer of the code doesn't find any of the comments to be applicable/usefuly, they can always go ahead and merge it right away.
Where I work I can and am still allowed to push to mainline directly, as are all other developers on the team.
Some new colleagues started with PRs and since then it has been a slow move towards using PRs more and more (but still not mandatory).
As of now some colleagues don't typically do PRs and push directly (minority), some decide on a case-by-case basis (I am among those, among a small majority in our team) and some have been using PRs for each and every change from day one (also a minority).
The criticisms by the opponents of PRs are as follows:
1. People relying on PRs too much causes them to propose code which is not production quality as of the PR whereas before (i.e. "no PRs") if your code was not correct, you or someone else either noticed shortly after (checking the tests on CI etc.) or it would make it into the release. I don't believe this to be generally true but sometimes thought similar when reading some PRs. The frequency of large bugs being found by code review in the PR has gone down in recent times which leads me to believe that the colleagues have adjusted their development style to come up with good quality solutions in the first attempt already in most cases.
2. Code review is hard to do in many cases. In our team this is typically resolved by going over a PR together for the “hard cases” (e.g. in a videoconference).
I think PRs are mostly worth the effort because any bug that can be avoided before the release saves a lot of downstream effort (e.g. support) and the effect of building a shared knowledge about the code page is valuable (although hard to quantify).
* Do regular certifications. Before certification, check if the document is up to date. If not, update it.
* Share the documents to answer teammates' questions. Like with a WIKI it may turn out that the important stuff is actually missing/undocumented/outdated. This is then a good opportunity to fix the document.
reply