xinu2020

I agree with the sentiment but I would add more nuance; you have to pick what is important to understand and what you can delegate; not all code is mission-critical.

In any case at the end you're the owner/accountable so you need to justify your and your agent choices.

Probabilistic programming languages that supports sampling are a good fit for these kinds of simulations.

estimating pi: https://playground.probl.dev/#code=ZchBCoMwEEbhfU7x40pRyiS4k...

(I'm the author of probl)

KSA works too and matches UAE pattern.

I'm tired of all the recents npm packages supply chain compromises, so I've written a collection of `sandbox-exec` rules to wrap all the `npm install` and `npm run <script>` of my projects on my machine. It works but it's messy, so now I'm working on a small rust tool that acts as a wrapper and generator for that so that it's nicer to use and can be shared to other people.

Their argument is that ln(z) where z is a complex number is a multi-valued function, so the statement "Explore why i^i is real number" could be misinterpreted as i^i = a single well-defined real value.

Except for the accountability part. That's the main feature of consulting.

Curious about this - How would local writes conflicting with remote updates be handled? I can't think of a merge strategy working on all scenario (or even most of the time)

For those who are curious how we can construct such a function, and why it looks so funky on the negative side, I strongly recommend this video https://www.youtube.com/watch?v=v_HeaeUUOnc

Alternatively pick a light-weight template engine from your favorite language and use it to generate the html. More flexible than plain html files and very low learning commitment.

I've been doing that for years and really happy with the result.

Why not both? It's not much trouble to publish a Dockerfile while still documenting a normal installation.

I was working for a fintech company that experienced a large growth (in the number of employees). The leadership team was keen to "grow fast" and on the surface it looked good: investors where happy, the company had a not so high yet but steady income (subscription-based) and each team seemed to have a purpose.

But in reality there were many issues: - there was a culture of launching "project/initiative" to justify more hires and promotions, rather than improving on the key issues we had (that nobody wanted to tackle). - People were often switching team after a promotion, for example leading a new team, and leaving their problems behind. - On the technical-side it was extremely tedious to contribute, we started with a monolith, then moved a micro-service architecture (with k8s, kafka etc). There was a push to do things properly, but it translated in over-engineering parts (for the cool stuff) while the valuable not-so-cool stuff was left to rot. At the end we had to maintain multiple things and the engineering effort to do all these migrations was huge, and took us away from doing more valuable work.

Eventually the company couldn't sustain its workforce and we had multiple round of layoffs.

My key learnings are: - Unless you are looking for a promotion before leaving (pump and dump), hiring a lot of people in a short amount of time is bad. - Even in best scenarios, having more employees make things harder and slower. People are competing for projects, there is a need for more communication, more processes, more tools. Having a lean workforce as long as possible, focusing on what's really important is best. - It's okay if we can't do everything we want. Not so many "ideas" are valuable and employees cost - Before hiring for a new project, can't we move other resources? Is this project really important or just a distraction?

Why do you suspect it is not ethical?

>What features could make it more ethical?

You should think the other way around, start with an ethical base, and only add features that keep it ethical.

I don't think this is much different to "when do you introduce internet"?

Both for "when do you introduce in a supervised setup" and "when do you let them use in an unsupervised setup".

LLMs are new to us, but for them it's not more new than the rest of the internet. It can be harmful, but probably less than social media.

>junior to mid level software engineering will disappear mostly, while senior engineers will transition

It's more likely the number of jobs at all level of seniority will decrease, but none will disappear.

What I'm interested to see is how the general availability of LLM will impact the "willingness" of people to learn coding. Will people still "value" coding as an activity worth their time?

For me as an already "senior" engineer, using LLMs feel like a superpower, when I think of a solution to a problem, I can test and explore some of my ideas faster by interacting with it.

For a beginner, I feel that having all of this available can be super powerful too, but also truly demotivating. Why bother to learn coding when the LLM can already do better than you? It takes years to become "good" at coding, and motivation is key.

As a low-dan Go player, I remember feeling a bit that way when AlphaGo was released. I'm still playing Go but I've lost the willingness to play competitively, now it's just for fun.

>The occupations with the highest exposure include mathematicians, tax preparers, writers, web designers, accountants, journalists, and legal secretaries.

I'm surprised to see "mathematicians" here, but what do they refer to? Mathematician as an academic position? As teacher? As consultant?

>Availability > >Available to Google Workspace Enterprise Plus, Education Plus, and Education Standard customers >Not available to Google Workspace Essentials, Business Starter, Business Standard, Business Plus, Enterprise Essentials, Education Fundamentals, Frontline, and Nonprofits, as well as legacy G Suite Basic and Business customers >Not available to users with personal Google Accounts

Also to be available it must first be enabled by a workspace admin, then by the end user.