One of the answers was (paraphrased), "because we're constantly recruiting for that title, but maybe not the same team." I'm not sure if that was a good or bad sign. Growth? Or constant turnover? Really makes you wonder.
I manage a highly stable tier 2 software team embedded in enterprise, and only recruit maybe once every ~2 years, if that. Hard to relate to what is going on these days.
If your company has 1k devs you'll have to hire several people every single week. At the same time if you want any level of consistency, you can't let teams who have not hired for 2 years come up with their own process, so that's why pipelines are a thing.
I assume most HN job posts are from small startups. Even if they are established companies with a sizable head count, it seems weird seeing the same exact job post month after month for a year or two straight.
> you can't let teams who have not hired for 2 years come up with their own process
Perhaps? We're a 9 person backend department inside a 250 person ISP. Not the typical type of team we talk about here on HN. I doubt small startups need a pipeline either, they just hire on demand.
I'm extremely anti-union principally because they drive up costs to consumers while yielding a product or service of at best comparable (but usually degraded) quality. Some easy examples are UAW destroying Detroit automakers or the recent dockworkers strike involving uneducated laborers demanding compensation ludicrously in excess of what even most people with master's degrees make, all to drastically under-perform equivalent workers from almost anywhere else in the world. To top it off, those same dockworkers zealously guard access to those highly lucrative jobs with some very questionable tactics.
When you drive by a highway construction project that doesn't progress for years or, worse, a horde of workers, most of whom appear to be doing absolutely nothing, there's a good chance that's union fuckery. When you go to almost any hotel in NYC and are treated with borderline disdain by highly incompetent staff while paying $500+ a night, that's union fuckery. When you wonder why you can't get cheap sufficiently high quality EVs like those from China, that's union fuckery. I could go on.
Unions are not comprised of saints. They're doing the same thing as the companies they despise: getting theirs while fucking over everyone else.
This is pretty cool. I manually put my budget for a month into a sankey generator just to see last year. Nice to see someone run that idea a little further.
Can’t really accuse programmers of being creative with words and phrases. Most of them will be rehashes of blogs and memes from the last couple of decades.
Parent is saying that California may not have the legal authority to regulate the internet in that way, since some powers are given only to the federal government.
Whether they do or do not have the authority isn't something that can be answered by anything but speculation until it's been tested in court, and I don't think any of the ISPs had enough to gain through packet prioritization that it was worth the risk of going to court.
"Ninth Circuit ruled unanimously in January 2022 that California's net neutrality law may continue to be enforced and cannot be overridden by the FCC as, current as of the decision, Internet services were classified as information services."
There's still one more higher court that can overturn that decision - SCOTUS. They could conceivably rule that no government agency, state or federal, has the ability to enforce such regulations.
That there was a hail mary appeal to the Supreme Court possible that they elected not to pursue does not negate that the issue is clearly not that the broadband ISPs didn’t see “enough to gain through packet prioritization that it was worth the risk of going to court”.
That's fair. SCOTUS is a roll of the dice lately, and there's no way of telling what crazy rulings they might back. As far as I know, though, that ruling hasn't been appealed.
Exactly. Even if their laws only technically apply within California, no car maker is going to build a car that cannot be legally sold in the single largest market in the US. It gets even more difficult with the internet as there are few internet providers who don't have at least some kind of connection to California and therefore fall under its jurisdiction, and ensuring you only apply prioritization to packets that don't involve California is extremely tough.
These emissions regulations don't cover just California, but most of New England, the Pacific, and the mid-Atlantic states as well. I think New York has a way to "fast track" new emissions laws from California, so that the states are kept in sync.
"California cars" were a thing in the early days when emissions were difficult to comply with. Even modern cars come with a "50-state compliant emissions" line item on the window sticker.
If California ratcheted up emissions standards too high, there's the possibility that such segregation could emerge again, particularly when it comes to trucks. There are already several trim levels of trucks that are specific to Texas, because the market there is so big. I could see a truck coming with a sticker that says, "RAM TRX can not be registered or sold in CA, WI, NY, [...] due to emissions restrictions."
I had the same idea about a decade ago but never bothered to try to implement it. I felt like it would have suffered from the same problem all other technologies have in security: overly complex user interactions. The concept makes sense, but getting N other people to commit is overhead the average user probably doesn't want to deal with.
So I preferred the idea of regular folks for backup, for security reasons. I thought of the idea of professional users like say your bank or 3rd party. The issue is that it's far easier for the govt to subpoena those pro 3rd parties and recover your key. Whereas, they would have to know which of your friends you used for key recovery to be able to do that. The idea was to make it tough for a bad/powerful actor to steal your key. Of course, the challenge is that a non social person would need friends or to depend on ISPs, banks (pro 3rd party providers). My goal besides security when building this project was to break the chain of 3rd party auths (Google, MS, Github, etc) :-(. They use their auth as a way to lock folks into their ecosystem and if you offend them in anyway, you could lose access to everything. Offend Google on adsense and lose your personal photos/email. Offend Amazon on sales and lose your prime streaming/AWS access. Hopefully as the idea picks up, the monopolistic corps can be tackled again to remove such power.
I wholeheartedly agree with where you were aiming your goals. Other thoughts I've had:
- What if access is time critical but your backup people are distributed across timezones? Or they aren't available for some reason? Could be hours to days before you could recover your account
- Adding/removing people as they enter/exit your life could make it a challenge to maintain (PGP + trust vibes)
Matanuska Telecom Association | Software Engineer - Systems Engineer | Full-Time | Alaska (UTC-9): REMOTE
MTA is an Alaskan ISP serving the southwest area of the state. The software team consists of 7 devs who support a relatively complex business enterprise environment. We're looking to add another Software Engineer and a dedicated Systems Engineer (DevOps) to our team.
As the hiring manager I want to be clear about a few things:
- This is a 70 year old enterprise telecom, not a high speed startup
- This job may interest you if you want great benefits and long-term job stability
- We have an existing environment running onsite on VMWare; the Systems role is designed to support, improve, and make adjustments to our tech stack over time
- Our core backend language is F# these days (replacing Haskell after 5+ years in production), frontend is React
- Our DevOps tooling is built around Terraform, Chef, Nomad, Vault, Concourse CI, Sensu, Prometheus, etc
The short version: The team had no problems with the language when I introduced it back in the day, but after writing over 300k+ SLOC of production code over 6 years we bumped hard into a lot of the typical ecosystem problems that tend to crop up in discussion. We still have systems we support written in it which won't be phased out for years, but no new projects will be written with the language.
If the team had been full of diligent Haskellers they'd have stuck with it, but they aren't really the type to align with a language/paradigm, and so a slow pivot into F# was decided ~2 years ago via a well documented RFC process.
I'm personally still a Haskell fan, but my hand isn't on the keyboard anymore. Not my place to make the tooling choice for them.
No one above me cares about this type of choice since we're a small backend department to internal customers. As long as the team is delivering results by the deadlines we commit to we get a lot of freedom to use whatever tooling we think makes sense.
> we bumped hard into a lot of the typical ecosystem problems
I think those are the things we really wanted to hear from you about!
I'm actively working on improving the Haskell ecosystem. I'm aware of a lot of "typical ecosystem problems" that cause challenges for onboarding of new Haskell users but I'm not actually aware of many problems for users who are onboarding and generally successfully using Haskell. I suppose general tool cruftiness might be one of those but I think it's a much bigger problem for new users than experienced users.
If you could mention the problems you ran up against I would appreciate it.
- Tool chain issues. Similar to the blog Nzen posted in a comment here, upgrading compilers could be a pain if breaking changes were introduced
- Poor ecosystem fit for an enterprise environment. We weren't willing to write libraries for some of the things we needed to support: DB2 access, SOAP, etc. Ended up writing C# wrapper services for a lot of that early on
- Poor library ecosystem in some cases. What felt like a good choice would be unsupported a year later
- Perhaps our own fault for committing to using Reflex for a heavyweight frontend. The team did an amazing job, but supporting GHCJS, the tooling around it, and trying to get faster dev iterations became a huge drag on the team
- Indirectly had to support it due to Reflex, but Nix. It's another rabbit hole that requires collective interest and a willingness to peel back the layers to make things work. Was another drag on the team
At the end of the day I'd say the biggest problem was cultural. I firmly believe that in order to have a successful Haskell environment, you need devs committed to the language and would label themselves "Haskellers". My team learned it and became expert engineers, but they are by no means Haskell language pros who thoroughly understand the inside outs of the language and its myriad of extensions. It's just a tool to them and they only used as much as they needed to.
There's a journal [0] on infinitenegativeutility, discussed here 40 days ago, with a section called "What pushed me away from Haskell?". That author points at issues that are primarily cultural. One example is a relaxed attitude toward backward compatibility from the GHC team.
If I grab an old Haskell project, even one without any external dependencies, I can often safely assume that it won't build any more with any recent version of GHC because everything has been changed just a little tiny bit.
That's an issue that would more affect experienced/long-term users than newcomers to haskell. I haven't used it myself. I'm just pointing at one person's perspective - someone who professes to still like Haskell - about why it's no longer a first choice.
We use this process to make some of the harder more nebulous decisions that require a bit of research and investigation from the entire team. While it does suffer a little from "decision by committee" we haven't ran into it as a problem in practice.
It's a great way to give people a chance to try and introduce new technology, processes, or paradigms. If they're committed they'll get the entire team excited and involved. If the team isn't interested it doesn't make it to the end of the process - and that's ok!
This looks interesting, but I'd like to double-check something - both job postings say "at our Palmer HQ facility", as opposed to your post mentioning that it's remote. Is remote allowed, or is it on-site?
Are you open to applications by senior devs from outside the US? You mention US work authorization, but on the other hand, this post has been up for a while now.
I fondly remember writing a Go driver for it. Was a good experience: https://github.com/riaken/riaken-core
reply