The reason that I was favoring Greyhole over ZFS is that I want to assemble a large, redundant storage volume out of a bunch of mismatched old disks and swap them out as they fill up or fail. I know it is very possible to do it with ZFS, but it seemed to not be the general use case and complicated.

No idea, but I am not sure your family member is qualified. I would estimate that a coding LLM can code as well as a fresh CS grad. The big advantage that fresh grads have is that after you give them a piece of advice once or twice, they stop making that same mistake.

Most people turn 18 during the last year of high school, which means that there is a very significant chance that the dev in question is still covered under child labor laws.

Maybe it is because I grew up in the North East United States, but when I was in high school, my classmates only worked seasonal or afternoon jobs.

I would be curious what the daily exercises are going to be. Is it just a 24 part tutorial on the etiquette around creating and contributing to open source projects?

C++ is unique in that it is wildly dominant in its niche. I am sure that any developer who has worked with another object oriented, manually memory managed, systems programming language (are there any other popular ones out there?) should have no trouble picking up C++.

Did you find the answer to your question, and if not, could you explain it better?

Also, a quick tip: if you are using Python 3, you don't need to join your variables before passing them into print. print accepts any number of arguments, converts them to strings, and prints them as a single line separated by spaces (which is exactly what your code seems to be doing).

In my opinion, Python is still missing one key feature: the removal of the Global Interpreter Lock, which is finally starting in Python 3.13.

We tried to ask our interview question of ChatGPT. After some manual syntax fixes, it performed about as well as a mediocre junior developer, i.e. writing mutithreaded code without any synchronization.

Don't misunderstand, it is an amazing technical achievement that it could output (mostly) correct code to solve a problem, but it is nowhere good enough for me to use. I would have to carefully analyze any code generated for errors, rewrite bits to improve readability (rename variables to match our terminology, add comments, etc), and who knows what else. I am not sure it will save me much time and I am sure it will not be as good as my own code. I could see using an AI to generate sophisticated boiler plate code (code that is long, but logically trivial).

The immediate use for this that jumps out at me is batch processing: you take n inputs and return n outputs, where output[i] is the result of processing input[i]. You cannot throw since you still have to process all of the valid input.

This style also works for an actor model: loosely coupled operations which take an input message and emit an output message for the next actor in the chain. If you want to be able to throw an exception or terminate prematurely, you would have to configure an error sink shared by all of the actors and to get the result of an operation, you so have to watch for messages on both the final actor and the error sink.

I knew basic CLI commands (such as cd and ls) for a while, but did not do learn much more. Some things have helped me grow my skills:

• Necessity: Some times I need to do something on a VM or container that does not have a graphical interface installed. Some utilities only have a command line interface and not a graphical client. My only option is to Google how to do it. The more I do it, the less I have to Google and the more focused my searches become (instead of searching for "How to do x", I search for "How to do x in utility").
• Learning from others: For many tasks, I follow internal or external guides, which typically use CLI commands. Often I look at how my coworkers accomplish tasks and pay attention to what commands they use. Then, when I have time, I look up any new commands I saw and decide if they will be useful for me too. Lately, I have been doing code reviews that involve shell scripts. Those are especially nice, because I can take my time, going line by line, and understand what each command does.
• Keep notes: Every time I find a command that I think I will need again, I copy it into a text file (and I have many such text files). It also makes it easier when I need to run the command with slightly different arguments (a different commit id or something), I can just edit the command in my editor (with searching and undo) and paste it in to my terminal with all the flags and arguments correct.

I also exclusively use the git CLI. I have tried to use a graphical client and could never figure out what it was doing and what was going on. I probably picked it up so easily because when I learned git, I was already used to using a CLI version control client. At the time, I was working at a company that heavily used Perforce and had a custom wrapper around the p4 cli that injected a bunch of custom configuration.