I didn't consider the lets them have their own cookies part, but I kinda like it, however I don't really know why other than I like separations of concerns. Why do you prefer that, and what scenarios have necessitated that in the past if you don't mind me asking?
Actual reason: because there are different firms administering these settlements. You want to separate these by subdomain so that there isn't a chance that an administrator from one site hijacking into another. Unless you're proposing the government to directly call/mail affected persons (might be desirable in cases like the JnJ Talc powder case where it is clearly a retail case).
All I see is the display of the egos and so-called philosophy of a bunch of rich "libertarian" punks who's basic MO is "I've got mine, screw the rest of you." They are as altruistic as a hungry bear.
If one of them walked up to me and said "I'm going to make your life better!" I'd have two questions: "How do you define better?" and "What's the catch?"
These are the type of people that push crypto cons and other destructive things.
They want to make the world better? Start by addressing the income disparity between rentiers like themselves and the people who actually build what they claim to have "invented".
IME it's arbitrary criteria - either last hired, first fired, or most expensive people, or older people (illegal, but they use other proxies for age to hide it), or most of a division because they're pivoting/no profitable, or you don't want to work 100 hour weeks sitting on the floor near your new CEOs office, or...
Getting laid off from some places is a badge of honor, IMO.
I'm less than ten years from retirement. I still need to work for those ten years, and probably afterward. Yes, I get a lot of ageism, ableism and sexism in my job searches. I don't look my age, fortunately, but having over 20 years in my field makes people want to lowball me or hire a "cheaper" (less experience) person. It's very annoying.
I get interviews with "coding challenges all. the. time. IDK why, I'm a Linux systems engineer, not a programmer.
But I constantly keep getting jerks wanting btree sorts that are like a college exam or take home challenges that assume I have industry type applications on my home network. No, folks, I don't run containers and terraform infra in my personal network. When I have to spend three hours to install a dodgy application just to start your janky "8 hour project" I lose all the enthusiasm I had for your job.
I've had bouts of unemployment lasting a year and a half. It's really hard to focus on side projects when you are worried about being able to pay the rent and health insurance and your pittance of unemployment insurance has run out.
My advice to anyone in the tech field is to try to have a lot of reserves, because tech is cyclical, and layoffs are inevitable, like every two to five years.
IMO it's partly a problem between sales and the "sprint" based development. Everyone wants fast, new and shiny and a 2 week sprint. No one wants to do tests, maintenance or even any architectural planning for their software beyond a single sprint, and architectural decisions don't flow between sprints. That's what happens when entire companies cargo-cult adopt scrum for their "agile" process, and the software suffers from the engineering equivalent of quarterly report syndrome (nothing longer than a quarter is really planned out in many publicly held companies because shareholder earnings reports are the highest priority.)
I think it's this, but this is just one symptom of the real problem, which is too many so-called "non-tech" people in the tech industry. There's no way a person who isn't a really good programmer (or something close to it) can effectively make decisions on a day-to-day basis. That's why managers have to guess or defer to a tech lead when it comes to real technical decisions/conversations (hence the tech lead who lives in meetings with the client).
To use a metaphor, imagine if a project manager at a car company boasted about "not being a car person", or couldn't explain how the main parts (like the engine) worked. Yet, this is pretty much the norm in many areas of the industry; tech is a cash cow, so it's attracted people with a desire for money where their knowledge and experience should be. You can't really fake it being a programmer, so they've only been able to infiltrate managerial positions.
(And to be clear, the way the tech industry supports people learning is fucking tops. I'm not talking about those people, I'm talking about people (mostly managers) who are not concerned about their basic lack of knowledge)
Another perspective... software in particular skews the usual production economics because of its low per unit cost vs the extremely high scalability and thus need for marketing and other business support.
A furniture business with ten people producing the furniture would probably max out their production with just a tiny bit of non carpenter support.
A software business with ten devs, on the other hand, could grow from tens to millions of users with the right non tech support, whether it's marketing or seeking VC funding, even if the underlying product only barely kept growing.
Most of these processes are there for business needs, not dev needs, with the company trying to maximize the value of their super expensive devs.
It's the assembly line model of software dev, where some higher up decides what to build and chunks it into individual production stations that each just produces their part with minimal fuss. In this world, managers don't need technical skills as much as waterfall skills. The spirit of it is completely different. It's not meant to enhance developer creativity but restrain it so that it's focused on a predefined chunk of business need.
Absolutely agreed. I'm on a team that is presently working on some rewrites of major components in our app from an older frontend framework to React with TS. It takes a while to get to even parity, it's tedious, and tricky to get right, and 3 of us are independently working on separate major bits concurrently. We also have other stuff, code reviews, meetings, Jira, other bugs to fix, and the 2 week sprint just makes it feel like I'm constantly on edge, because it's not going to be anywhere useful in 1 sprint or likely 2, and it doesn't offer any breathing room. Having more two week blocks rather less longer blocks of time also introduces more of the overhead that accompanies agile crap, and reduces time to get the stuff done even further. If we know it'll probably take 4-6 weeks to do something to the standard we want it, we should probably at least be doing 3 week cycles, or dynamically change it depending on our goals, but that never happens.
2 week sprints optimize for fast, poorer quality work, and much less of it, because for a healthy practice one needs margin. Margin to accept other pointless meetings, margin to deliver hotfixes, margin to do work carefully without burning out.
You're not the only one. I too am also doing somewhat of a similar migration with similar staffing and not enough time, and the project managers and product owners are more concerned ed about the dates they committed to than what us devs need to make it all possible. The last site works, but it has dragons and monsters under the hood.these things take time, but because us devs are not able to clearly estimate.the end of the line, we stick with the too tight time frames...
Yeah we have 2 week springs inside ~quarter long projects. But I find the projects come and go and I'm still providing weekly user support for projects that "ended" quarters ago. Like there's no company dialect word for "platform".
Mirrors my experience somewhat. Often these places are feature factories that heavily advertise their scrum/agile practices without actually thinking about if they apply or fit (or are even implemented correctly).
What often follows is a thick layer of success theatre with each feature release.
Rinse repeat.
Any voices trying to point the flaws, inefficiencies or low hanging fruits for doing things better are drowned out or made to feel the odd one out.
IMO it's just new for the sake of newness. Apt and dpkg work fine, but some folks feel they have to reinvent the wheel, I guess to beef up their resume or be more like MS or Apple. If they want to write MS or Apple style software, they need to just go and work for those companies.
Apparently some people think that Linux should be just as deterministic and user limiting as proprietary software. I don't understand it, personally.
IMO dnf is ridiculous newfangled garbage too. Why do people keep reinventing the wheel when it comers to package managers? Apt for .deb and yum for .rpm work fine, manage dependencies, and Just. Plain. Work. without f'ing up the system with autoupdates and bloatware. Seriously, an open source project is not for junior programmers to push their resume driven development on the rest of the community.
dnf is way better than either apt or yum. (Somewhere in my HN comment history I've written at some length about this.)
Major points:
- dnf has a more complete dependency resolver than apt uses by default
- the notion of vendor change is extremely useful when managing multiple repositories on a system
- modern subcommand interfaces are great, and dnf's is stable and mature whereas apt's is still experimental
- dnf handles repo management itself. apt doesn't
That's why I hate Snap. In Linux, unlike Windows or Mac, I should not have to fight my tools in order to configure a system the way I want it. Yet Ubuntu makes me do it every goddamn time for anything on the desktop, between snap and their nasty "Unity" desktop.
