Apps running locally can also be subject to security issues. What you're trying to say is probably "apps not using untrusted input". If an app takes no input all, I guess we could say that security isn't an issue, but there could still be safety issues.
Strongly agree with your second point, too many times I had to figure out issues caused by code trying to handle errors but actually hiding them and making it so much harder to debug. The typical antipattern: catching SomeErrorType just to log "error of that type occurred", thus hiding the associated error message and the stacktrace. Even worse: trying to catch every error types.
Don't catch errors unless doing something actually useful with them. Even then, it's often a good idea to re-raise.
I also believe people throw way too many exceptions. You should be able to be explicit about the outcome of an error case, and not just throw exceptions in a panic.
So alongside swallowed exceptions is throwing exceptions in scenarios that were entirely recoverable, and I think in both scenarios devs just don't understand their program enough and are choosing to panic, or ignore the problem.
I think people often throw exceptions rather than write the code that handles the situation more gracefully. If you knew it could happen, then is it really an exceptional circumstance?
I think it's impossible to come up with a good rule of thumb for error handling. Sometimes catch-and-log is what you want. Sometimes catch-and-reraise is what you want. Sometimes let-it-fail is what you want. I really cannot come up with a good argument that one of these is the better default. Languages should force us to consider which failure mode we want for every function that can possibly result in error.
The most egregious thing to me is the fact that most languages let any function throw any error it wants without requiring that be documented or part of the type system or anything.
I try to make sure that the failure happens as close to the cause as possible. For instance, validate input when it's supplied rather than when it's used.
- Sometimes what’s best for the system isn’t what’s best for your job
Fail fast is a good ethic but all to often I’ve encountered applications that are only to happy to limp along for the sake of optics. If that’s the prevailing sentiment where you work I’d recommend against violating it off your own bat.
I think this happens because people don't treat the testing code as "production code" but something else. You can have senior engineers spending days on building the perfect architecture/design, but when it comes to testing, they behave like a junior and just writes whatever comes to mind first, and never refactor things like they would "production code", so it grows and grows and grows.
If people could spend some brain-power on how to structure things and what to test, you'd see the cost of the overall complexity go way down.
As a developer who doesn't use AI for coding, except for the occasional non-project specific question to a chat bot, I am wondering if you use it for client projects or only for your own projects. If you do use it for client projects, do you have some kind of agreement that you're going to share their code with a third-party? I'm asking because most clients will make you sign a contract saying that you shouldn't disclose any information about the project to a third-party. I even once had a client who explicitly stated that AI should not be used. Do you find clients willing to make an exception for AI coding agents?
I basically only use it in the workplace, and largely because of one of those AI mandates.
I don't think it actually saves me enough time (or for many tasks, any time) so I wouldn't pay for it for my own projects, and also for my own projects, the enjoyability is a big factor, and I enjoy doing more than prompting.
Sadly, I mean my current employer is doing the whole "tracking to see AI usage rates" and basically checking in performance reviews if people are using as much AI as the AI sales people told the CEO people need to use.
Klarna, Shopify and either Google or Meta made a lot of press promoting policies like that and also the AI companies themselves are selling this kind of approach in the "how to make the best use of our tools" advice they give to execs.
I have a client that actively asks me to use AI more and more. They expect to get better quality code faster, ie. to reduce costs. (That's not my experience but that's beside the point).
Precisely. For work projects, I only send contexts I've specified myself (so I might copy-paste a chunk, clean it, then send), I don't let AI tools pick and choose what they need.
If I were using it for some hobby project or open source thing I would probably be more open to experimenting with sending random parts of the codebase.
Oh OK my bad, I didn't get that. Seems like a strange idea to me. If money is the issue, you can probably find a decent second hand MIDI keyboard for a very reasonable price.
