Regulation, my man. Doesn't require fitting into the existing framework that was invented to as a stopgap for dangerous factory working conditions. The barrier is people's preconceived notions on what work day, weeks, and lives have to look like.
Nobody said homesteading is the solution. Allowing a parent of young children to care for them is not a radical idea though. It should not be hard to imagine a society that is more flexible to childcare being performed by parents, because that was the norm for all of human history prior to industrialization. People should seriously consider the ways in which their imaginations on this subject (and others!) are constrained by their post industrial upbringing, and importantly, why the current norms exist and who they benefit.
As someone who grew up homesteading and seeing the benefits of it, I find it wild that people want to not only send their kids away to school full-time but also institutionalize them afterwards just so they can spend seemingly excessive amounts of time at work. The economic machine demands sacrifices apparently.
The email was sent from the 'npmjs dot help' domain. I'm not saying you're wrong, but also basic due diligence would have prevented this. If not by email, the maintainer may have been able to be compromised over text or some other medium. And today maintainers of larger projects can avoid these problems by not importing and auto-updating a bunch of tiny packages that look like they could have been lifted from stack overflow
You've touched on some interesting points here. I have also felt the entitlement, but while contemplating why it exists I came to the conclusion that it is due to a misplaced belief that open-source primarily benefits the individual and as such is a righteous crusade. While individuals may become beneficiaries in particular use-cases, I would argue that it is actually corporations that benefit the most, and not by a small margin. Just think of all that labor they get away with not having to pay for and all that specialized knowledge they don't have hire for. Then they also benefit from publishing libraries to end users so that their platforms may be more deeply integrated in customer's tech stacks. Meanwhile the guy maintaining the various open-source libraries that underpin those commercial services doesn't get anything at all. One might even be able to claim that open-source is predominantly an upwards transfer of wealth from engineers to executives.
It's not possible to rug pull an open-source project by just switching new work to a different license. The real issue with open-source is that we don't live in a utopia where you can publish all of your work for free and still live a quality of life comparable to working at an average developer job, and yet so many non-maintainers somehow feel they are owed future labor. Maintainers come and go. Without sponsorship, the half life on maintainers is going to be relatively short, and more developers are going to be pushed to publishing less permissively.
I understand that is the Go philosophy. I care more about what is practical than dogmatic. It seems clear to me as a complex library author that the type system leads to way too much glue code, which is expensive to write and maintain.
Is it possible that some of the mismatch in how people view Go's type system is due to experiences differing from writing applications vs writing libraries? I personally find some of the repetition in Go code to be tolerable when writing web applications and CLI tools, but a real issue for the composability of libraries with different purposes. Going back to the database toolkit example, the query builder can easily return a result type, but what if I also want to handle validation of input before the query and then later return a HTTP response? Well to chain a result type end-to-end in Go requires it to have knowledge of all the different types/interfaces that it could map to, which I believe is way too broad of a responsibility for one type, even though all of those features feel as though they could very naturally chain together and reduce down to a single error. These kinds of type limitations effectively force Go libraries to live on their own islands where they don't compose with one another.
That's a complimentary point, not a counterpoint. I'm talking about Go's type system being restrictive. PHP and many other languages avoided that particular trap by allowing variables to be reassigned to any type. Java and many other languages went in a different direction and instead chose to build more complete type systems.
The reason Go does not have a grand framework is that the language has a severely underdeveloped type system, which makes building complex libraries that meaningfully complement each other overly difficult. I waited nine years before starting on my first Go database toolkit so I could use generics. I succeeded, but can't shake the feeling that I know I had a better experience doing it with Java in undergrad. Being able to map/filter/reduce from a result type into another generic type would be a complete game changer. Being able specify union types would eliminate my need for the "any" type. Being able to overload would clean up a lot of code. It needs more time in the oven.
It's not clear from the article, but is this for local development or production deployments? Because it's worth noting that Swarm solves a lot of the limitations that Compose and Podman have for running containers in a production environment. Swarm runs well on singular vms and people with Docker experience can learn the ropes in a day.
Where did you see that white collar jobs are in a free fall? The employment rate is still tightly correlated with level of education as it always has been.
Hey, first of all sorry to post this so many days late, I just got here looking to see if this article had been posted already.
I think the piece you are missing is that guilds exist to protect workers, not consumers. US software engineers not feeling as though they need the protection of guilds means by extension there are no non-government bodies to enforce codes of conduct. It is also worth mentioning that, although limited to specific high-risk use cases, software engineering is regulated.
The problem with these discussions is that almost nobody outside of the agency/contracting world seems to track their time. Self-reported data is already sketchy enough without layering on the issue of relying on distant memory of fine details.
Results like these are only possible when engineering leads have completely lost the plot. The checkout taking many minutes longer, if true, is bad enough that I doubt the problem is purely UI bloat. Either that or the benchmark itself is cooked.
People love to make these weirdly diminutive comments about programmers, precisely because programmers are crushing it. Meanwhile most of the economy has been diverted to attempting to replicate the abilities of even just an entry-level drone who copy/pastes off Medium articles, which itself is heralded as a miracle.
10x has always been an exaggeration, but I know from repeated experience it is possible to complete projects far quicker than 2x the speed of the typical team on a modern web stack. The way you do it is by writing less code. Typically this is done by using mature software as a starting point, rather than screwing around with the hot new thing. Seems fairly obvious when stated plainly, and yet so many teams make the same mistake of building from near scratch. Even worse, what teams come up with is usually slower to iterate with than existing software, because they approach it from the perspective of building a singular app rather than designing something to build generalized solutions upon.
In this industry they do. You know that companies using these tools are exercising minimal effort and due diligence, and that should be taken into consideration before participating. It only makes sense to play the high-volume application game if each application takes negligible effort to submit. The people I've known that have gone that route have had <1% success rates. For quality candidates, a lower-volume targeted approach will yield the best jobs and retain your sanity.
I think it is right to call out HTMX as being a wrong approach for custom form elements. Try a progressive enhancement approach with something like Turbo, where you can still write JS as needed. This wizard could have been more elegantly implemented by removing the server requests for each step and just showing/hiding fieldsets on progression.
Finding good (and available) primary care providers has always felt like going to the casino in my experience. Currently seeing an older NP who has been great. I could see a future with many more NPs. Obviously, if you know a guy or need a specialist, then do what makes sense.
> but if I was choosing between two jobs where one was utterly boring but paid 3 times more than a fascinating job, I'd take the latter in a heartbeat.
I chose my current job against competing offers because it was a good thing for the world, but I would not have taken significantly reduced pay for it. Let me tell you why: nobody that insists on paying you below market rates is going to treat you right. Some of the worst professional interactions I've ever dealt with involved high ranking individuals at nonprofits. These were orgs may have had genuinely good missions, but also paid rank and file employees quite poorly. On the other side, the 3x above market rate job is just a fantasy. I could believe it if you were talking about a 20% bonus.
Standards vary wildly on what constitutes a fingerprint match. There can be well over 100 ridge characteristics in a fingerprint, but some US jurisdictions only require as few as 12 of them to match, and it all comes down to an investigator's subjective determination anyways. It is not scientific.
Signatures are the tip of the iceberg. Plenty of other forms of bs forensics live on in the legal system in some shape or form. e.g., fingerprint analysis, polygraphs, field sobriety tests, devices that literally do nothing, trainings on reading facial expressions, and so on. If you can take a two week course on it, then chances are there is some cop somewhere using it to detain people.
The police committing accidental/negligent discharges of their service weapons has been a nearly constant source of social unrest in the US... Great example of how people carrying loaded firearms is a public safety hazard.
Can't pull when someone randomly has the drop on you chambered or not. Have to retreat/conceal first anyways. Far more likely to have a tragic accident than ever saving someone. Not long ago someone accidentally shot the neighbor's house right into the bathroom. Accidents happen way more frequently than random crime and should be the top concern for gun owners.
Developers can only be as good at their jobs as their environment allows them to be. Based on the commit log for all authors, my takeaway here is that this is a legacy software project that needs better test coverage and to establish standards around adding tests when merging in contributions.