This is one reason why whenever I build a new project, I build it inside of a Docker container.
That way, the project has just the dependencies it needs, and I know I can rebuild it at some point in the future and will be unlikely to run into problems when I do.
This works as long as your Dockerfile is reasonably reproducible and does its best to lock dependencies. However, this approach has failed me a couple of times in the past. For example, I rebuilt a container some weeks later, in the meantime a new version of clang had been released that just so happened to break my build due to a bug.
I personally use Nix these days, but the complexity is too high for me to recommend it to everyone for every software project.
Yeah, Nix pretty much solves this problem. The other day I wanted to try a really old version of spaCy for fun/historic interest. spaCy 1.8.2 installed freshly from the binary cache on NixOS-unstable as if it was still April 2017.
My first step now when trying to resurrect old projects is to create a Docker container for it - that way I can install any old versions of anything (like node or PHP) I need without having to worry about it polluting anything else on the system.
Using CAs and signed certificates in SSH is definitely the way.
If anyone wants to play around with that, without the risk of locking themselves out of a server, I built a little "playground" awhile back whihc is a series of Docker containers that can SSH to each other. Give it a try at https://github.com/dmuth/ssh-principal-and-ca-playground
(I haven't touched the project in awhile, so if there are any issues, please open an Issue and I'll gladly look at it!)
I can offer what much younger me was once told by a senior engineer:
1) With respect to not having whitespace: "Not everyone is as smart as you, and you need to ask yourself, do you want junior engineers working on your code to keep bothering you asking how things work, or would you rather your code by easy to read (and commented) so that they can pick things up on their own?"
2) With respect to complexity: "We are expected to build products that align with business objectives. New and experimental code belongs in your home lab and on your GitHub, not in a production environment."
Depending on how things go with #2, maybe offer to let the engineers spend 20% of their time working on lab projects to improve their product, with the understanding being that the rest of the time they are expected to build products with a minimum of complexity.
I can agree with the spirit of #1 but also I think it has a subtle bad implication. You do want your juniors to talk to you and you should want to talk to them. You should also want to push them out of their comfort zone (slightly at least) so they can grow.
For #2, I don't think it's fair to say complexity is always equivalent to "experimental." We're getting close to conflating code that takes skill to write with code that has no benefits or will be buggy/experimental. The OP doesn't really deny that his engineers can write this code without failing at it or that it wouldn't improve the product in a measurable way. The post in regards to complexity is really more about the spirit of your first point in which he thinks some subset of his team can't easily deal with this type of code.
I would say that "complex" code that provides a measurable benefit and that some of your team can "wrangle" isn't necessarily a bad thing. If you want your product to be differentiated and better versus your competitor's product you're going to have to do this. If we all program (100% of the time) solely to lowest common denominator on a team(and I don't mean this disparagingly) then the company's product can only be as good as its "worst" engineer.
Otherwise, we can all get off of this site and build the same todo app from the same step by step tutorial :)
Generally agreed with this, and I had a similar experience.
I think overall it comes down to trying to help them build empathy by showing them that they aren't the only one that will have to interact with what they build, as they are a part of a team.
An easy way to start is, like the parent suggests, with showing "How does making it easier to read or reason about ultimately benefit you?" (e.g., not having to be asked for help by junior engineers). The downside of this is it's kind of abstract, and ultimately a selfish motivator ("what benefits me?" over "what benefits the team?"), as another commenter mentioned.
One option that might be more tangible and team-oriented is to discuss design options as a team. Hopefully in doing so they can understand the complexity in their approach as other people ask questions. If you're able to structure in such a way, one trick here is to separate the design phase from the actual implementation phase. So, whoever designs the approach isn't the one that implements it (within reason -- you could also pair program here, with the whoever designed it as a reviewer and not the primary).
Some of this is also about them realizing what is obvious to them is not obvious to others. One tell here is if they use "why don't you just..." a lot when asked questions.
One phrase I use a lot on my team is "don't be a hero". Heroics in a team setting (willingness to write overly complex features, take on indefinite maintenance of code they wrote so others don't have to reason with it, etc.) are generally detrimental to the team overall. If they find themselves having the need to "carry the team" a lot, you could direct some of their energy/problem solving towards how they could help up-level the team overall or fix team processes.
Anyway, a bit of a ramble, but that's my 2 cents. YMMV.
It lets you create a Git repo with synthetic commits and has sample exercises for doing different things within that repo, such as removing commits or squashing commits. (along with hints and answers)
Building this project helped me understand the ins and outs of Git much better and I suspect there will be value for anyone else who works through the examples.
