The principle behind a lot of good advice here is “creating the conditions for solder to naturally go where you want it to”. Cleaning, tinning, preheating are all part of creating those conditions.
So the moment you find yourself fighting or forcing the solder, it’s better to step back and create the right conditions.
Bleak. This flat and fast structure assumes that ICs are all senior devs, able to be largely autonomous. Who supports the junior engineer who is struggling?
There’s a lot of talk about how AI shifted the job market away from junior roles, but companies had already removed the management capacity for them.
Is there a newer 'be autonomous' culture? Or did I just grow up a bit?
10-20 years ago people would love to talk about technical topics. Ask help, give help, offer pointers, debate merits.
Now I guess we ask AI, figure it out ourselves, and/or grin and bear it?
What happened? Is it from remote work? Or everything's easy now? Or nobody wants to stick their neck out? Time constraints? Knowledge gaps?
I don't struggle, exactly, but I run up into all kinds of situations where there's no obvious best choice (everything's awesome and everything is too limited all at once), so either some tough choices need to be made or maybe there IS a better way but it's just VERY non-documented or too much of a PITA to do right away (or simply, silo'd and well-protected).
There ARE avenues to get things done. There ARE multiple valid channels to ask or follow up in. The answer is basically: do it, don't ask. And yet...
GIVEN an culture/expectation/want to be "autonomous" (heck that's what agents need to be, mostly), I think something is missing.
It's like people learned somewhere "be independent", "be autonomous", "don't require help" as somehow "virtuous" outside of the "normal" bounds.
Am I the only one noticing this? Or did something shift?
It's a new culture. Combination of AI making junior engineers redundant, new grad skill levels cratering if they used AI to skate their way through college, and filtering through job applications being functionally impossible with huge floods of perfect ai generated resumes etc leading people to fall back to hiring through their network instead of applicants from open listings (and senior engineers are going to have better developed networks). And at least personally (+ for people around me) - AIs increased productivity comes with increased cognitive load and workload.
Plus you don't want to take a risk on training a new grad anymore because usually they'll leave after a couple years, which was a good thing since you'd backfill with a new grad some other company had trained/ideas circulated in the industry/early career engineers built their networks and got exposure to different tech stacks and company styles etc. that's really tough now too since nobody else is hiring and training juniors so you would be wasting time and effort training some for some other company to hire away - nash equilibriulm vibes.
So yes something shifted- the new grad/junior market is in the gutter rn. And if AI plateaus in this range of capability idk what happens as the current generation of engineers age out/retire. The juniors that aren't being trained today are going to lead to a vacuum of senior engineers tomorrow.
There looks to be some errors in the conversion from PDF -> web in this report. For example, the web version of Figure 7 has the legend colours reversed.
I'm not a lawyer, but I've asked these kinds of questions to lawyers.
Paraphrasing, the answer I got was: "Anyone can sue anyone for any reason, and then we have a legal process to determine the result. If you're a director of the company, they're probaby going to sue you personally, and you're going to have to spend a lot of money to argue that you personally shouldn't be liable. Hopefully you'll be successful. It'll all depend on the facts, so you'll need to get sued first before I can give you a better answer. Either way, it's going to cost you money."
My conclusion is that the legal system is not super great when a bad-faith actor is involved. Though, really, it's also not super great when good-faith actors are involved, either.
Some of the defendants (the developers of Bitcoin ABC now called eCash, an alternative cryptocurrency based on Bitcoin and its blockchain) had organized their development under an LLC. Hasn't helped so far, though in the unlikely event that the case is ultimately lost it might help them constrain recovery of damages to the assets of the LLC.
I think in general structural improvement like that are most effective against 'honest' opponents-- someone whos goal is to win and recover their costs and damages. A legal structure that limits liability makes recovery less likely, so they don't bring the action at all.
For an opponent who's goal is to harass and ultimately crush the opposition, I think that kind of tool is probably less effective. It's also harder to justify doing when you're just following a volunteer passion over something speculative and worthless (as was the case of the Bitcoin related defendants-- almost all of whom started close to the beginning of Bitcoin).
[And as an aside: to the extent that development is done on an uncompensated purely voluntary basis, it would be difficulty to legitimize the LLC, e.g. little to no income or expenses or other documentation that the LLC is anything but a piece of paper.]
But this also follows along the answers "since you're not in the UK why not ignore it"-- if a court later decides to allow recovery of assets that came from the LLC or pierce the corporate veil entirely you're screwed-- at that point you lost your chance to defend yourself.
Recommended a scheme to shield OSS developers from liability. I am not a lawyer, so it looked a bit overly cautious to me, but it seems that was a good idea.
The liability isn't really on the software itself, but the fiduciary responsibility that they _might_ have through their supposed control of the Bitcoin network through their control of the official software repository.
A Ltd company would help a little, but individuals within a company still have fiduciary responsibility.
Nope; in fact, the MIT license isn't really of consequence here except in that it doesn't address a possible fiduciary/beneficiary relationship with users.
> I want you to act as a machine learning classifier. The training set consists of news topics and the label categories are “politics”, “celebrity” and “finance”. I will type text input and you will reply with what the classifier output would be. I want you to only reply with the output and nothing else. Do no write explanations.
Very cool idea. That'd be a good way to see how it can generalize, actually. I suspect you'd quickly find its limits with something that isn't a toy example of an intro to machine learning.
GPT-3 has been trolling simple examples too. I think it comes from what it crawled. You will find very few conversations like that with just correct data, what gets popular and how jokes are made is when there is a twist.
It's true that there are a lot of limitations still, but I think you are underestimating how powerful it can get with the right input prompt. For example for your task I wrote:
>You are a professional puzzle solver. Only answer with the element in the list that does not fit. Do not include an explanation. Do not write anything except the element that does not fit. Dog, 1, 2, 3
Dog
>Computer, Phone, Tree, Microwave
Tree
>red, blue, green, dog
dog
It seems to perform quite a lot better in my short time of testing than before which seems quite extraordinary to me. Now that is not to say you can't find a bunch of examples where it fails or that it is even close to human level for this particular task. But this still seems like a huge technological advancement to me and I did not expect that ai systems would be at this level quite so soon.
> The word "dog" does not fit with the other words in the list because "1", "2", and "3" are numbers, while "dog" is a type of animal. The other words in the list are all examples of numbers, whereas "dog" is not a number.
Post doesn't make sense. It clearly states that you only be sure that package is working by actually installing it into clean virtualenv and testing it there. `src` or any other layout doesn't matter.
The difference is if you're running tests from your root project directory, the package is importable regardless of whether or not it is installed, as python picks up packages in the current working directory by name. src/ prevents this.
This is almost exactly how I set up python projects; it’s reassuring to see it set out in one place.
I started using tox-poetry-installer[1] to make tox pick up pinned versions from the lock file and reuse the private package index credentials from poetry.
So the moment you find yourself fighting or forcing the solder, it’s better to step back and create the right conditions.