Surely you meant someone like John Stuart.

Check those in to source control and it kind of takes care of that (except passwords/secrets or configs which have them).

You are more optimistic than the maintainers of those older projects that have started to ban LLM generated bug reports. They tend to be a waste of time for the maintainers (e.g.: cURL project).

Macroslop*

I wouldn’t. Why would I bother at this point. Their commitment is to making money, not customers.

I found a git repo with docker compose and the config files works well enough as long as you are willing to maintain a backup of the volumes and an .env file on KeePass (also backed up) for anything that might not be OK on a repo (even if private) like passwords and keys.

It means you are invited to the most pointless stuff because someone from the team needs to attend and you have more experience on how the different teams interact (ideally, some people are there for the potential higher salary most companies structure management under).

Nothing of note happens 75% of the time (maybe being generous there). You just don’t want it to come to your team last minute about 2 weeks from release with high priority because it was “already discussed and agreed to” on some obscure 2 hour inter project planning session (recurring very boring biweekly meeting).

I had more power to affect things as a senior developer than a team lead on a previous company since I could actually make technical decisions and my boss (great person) trusted me since I spent most of my time trying to learn things (since I had the time to do so without the meetings).

I won’t tell you it could not work since you are allowed to make some calls based on your experience and intuition, which is nice and rewarding, but have realistic expectations to avoid being let down.

At least they ran trials. I feel the federal gov’t would just buy the shit with our taxes.

What’s the expected volume of records planned to be stored?

For a small volume on a school assignment (a few thousand records on each query), I would do a processor/filter on my base database access layer and do the encryption and decryption there for any field annotated as @Encrypt at the field level or similar (language dependent, not sure what you are using).

Some libraries use a similar approach during serialization and deserialization steps. I’m guessing you are required to write the whole thing, but reading how those work might give you ideas since they tend to have hooks to wire custom logic during the process.

This would add overhead during read and create, but would be pretty transparent to the rest business logic and as mentioned, as long as the requirements don’t say you need to support searching over a few million records in X amount of time, it might be OK.

The hash idea sounds quicker at first (hashing vs on the fly encryption/decryption), but it does not sound like it would scale well either unless the message size is constrained like you mentioned. Another problem us that it could be extremely easy to brute force with a rainbow table which kind of defeats encrypting it to begin with. If pursuing that approach, you’d need to also store a salt with each hash to prevent that attack type.

Custom encryption solutions and security through obscurity tend to be the weakest points in an implementation, which sounds like is part of the assignment to think about.

There’s going to be plenty of idiots that will see the never proven mostly unusable robot as a good thing for the company. Another trillion dollar bonus package approved!

I still get a bunch of AI bullshit unless I go out of my way. Also I swear they keep reactivating it as much as google when you opt out (or select ddg no ai as your search engine in Firefox and still see that garbage).