Beyond the content, I'm pleasantly surprised to find this website design easier to read than most others.
29 karma · joined June 4, 2025
I expect to not be the only one, it certainly drives usage KPIs up and lead to this kind of decisions.
It's harder during crunch or when everyone is remote.
When scheduling onboarding, I try to enable touring without those drawbacks.
Currently in maintenance tough
This is the reason I wear headphones, I don't even switch them on.
It seems to be less broadly understood than before and my work is often disrupted.
Finally the job didn't correspond to his profile and objectives. I have not checked if he improved it later, I guess he did.
I wouldn’t express an opinion on the subject, however, I’m glad when information is made public, as it allows everyone to weigh whether it should influence their decisions.
Why skip Mullvad ? I thought it has a great reputation.
Watchmaking can take a heavy toll on eyesight, due to working with magnifying glasses on tiny parts during decades. Also each brand has unique processes and machinery, for which they have expensive learning courses.
Thus they would rarely consider applicants past their forties even if they have experience and favorable relations.
We're guessing it comes from organizational behavior (culture, governance, management, etc.), we work in diverse teams / regions / companies.
I find bewildering that such concepts are tried only centuries later, and wonder how it comes to be possible. Is it that we can finally enforce them, or that the lobbying have been gradually weakened, or enough data to drive decision, etc. ?
While taking ownership of AI slop is not an option for me, I do want to avoid shadow IT.
Might be a moon shot .. could sharing a prompt template with git access to colleagues be a way to enforce it ?
Also I believe the value is in the output, not the app itself. ROI of a 1 hour AI slop should™ be attained before it rots and they can just spun up a new one.
I might be hopeful and a bit selfish here, I expect my colleagues to own their toolbox.
Some users with privileged access can run their app locally in cli or browser, else most softwares we work with can use custom modules in specific languages (html, css, js, dax, vb.net, perl, python, sql, etc.). Ownership and trust must be established, for example only the commercial manager has access to deploy modules to CRM. They usually are constrained to read access, unless they are informed engineering managers.
Ideally I would share pipelines to deploy static pages, or a predefined dynamic architecture. I'm wary the security risks are too great, I don't trust they would have enough time / interest to become autonomous in unconstrained environments so I didn't pursue the idea, maybe I could for static pages, or in isolated networks ..
I've observed a new trend, managers who are frequently in the wait list started to use AI to generate small local apps. They still rely on my input when it's complex, or when implementation could generate risks or need resilience and would ask for small code reviews when they are unsure of the generated code quality.
The result is win win, I have more time for high value projects the executives want to prioritize, and managers can innovate faster almost on their own.
It also allows running multiple instances with a single account (to be on multiple vocals at once for example).
The only drawback is the release cycle is more frequent and I need to update every time I boot.
> Good catch, it misled me for years !