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.
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.
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?
>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.