mkipper

Unfortunately I don't think there's a good way to find these companies unless you happen to live near them or work in the industry they sell to.

In my experience, they normally get started and funded by local people in their industry and they sell back to local customers (at least initially) from their network, so there's very little in the way of advertising, especially at a national level. Also, they often hire from their network for early positions and local colleges/universities as they grow, so you might not even see them on job boards.

If you're looking for companies that are a bit more established, you could try industry trade shows.

Another consideration is that a lot of hardware startups focus on industrial applications with customers that don't operate out of tech hubs.

There are tons of small companies making hardware for oil & gas applications, but you'll mostly find them in areas where their customers are located (e.g. Texas, Alberta) and/or LCOL cities where you can find cheap real estate. This also applies to other industries like agriculture and automotive.

These aren't "sexy" companies so you don't hear much about them, but I'd wager that if you add them up, they'd outnumber the number of hardware startups in NYC and the Bay Area.

This has been the policy at every boring non-tech company I've ever worked at. You get hired with a certain amount of PTO, and that number starts to grow after some initial waiting period (e.g. 3 years). It's not uncommon for company lifers who have been there for 20+ years to have doubled or tripled the PTO they had when they started.

That being said, I've never heard of a place that _literally_ ties PTO to tenure -- if you join the company in a senior position, you can always negotiate to start with a similar amount of PTO as someone who worked their way into that position internally.

> I think an IPv8(Apparently we skip odd numbers)

A lucky few of us have had the pleasure of working with ST-II, AKA IPv5:

https://en.wikipedia.org/wiki/Internet_Stream_Protocol

This is what worries me the most when it comes to job losses and downward pressure on wages.

If we hit the point where a senior engineer reviewing the output from an AI can effectively replace a team with a senior engineer and 5 junior engineers, you’re right that it isn’t wise to simply replace all those junior engineers with the AI. Unless you’re confident that the AI will be able to replace that senior engineer soon, you _need_ junior engineers who can build up the experience needed to step into that role once the senior engineer moves on.

But you _can_ get rid of 3 or 4 of those junior engineers. The remaining junior engineer(s) will still need mentorship from the senior engineer and will still do “trivial” work that needs oversight, but they will be able to pump that out at a high enough rate to replace a few of their pre-AI peers.

Basically, I’d imagine the org chart at most companies will look pretty similar to now, except you’ll just have fewer people at each level.

That's not my read of it at all. You could make the exact same comment without any mention of Europe -- it's pretty unlikely that a hedge fund manager in NY would hear that comment from someone in their social circle.

Sure, but I don’t think that’s necessarily helpful in the context the OP is describing. If you bring up concurrency in a software engineering interview, you’re probably hoping the candidate can speak to different synchronization techniques, their pros/cons, how to implement them and how to use them.

Anyone who can figure out timing in a complex digital circuit can learn how threads and mutexes and message queues work, but there’s a good chance a CE grad would not be able to speak to those topics very well compared to a CS grad.

Again, this isn’t a criticism of CE. I just doubt OP would have their socks blown off in the areas they mentioned if they started interviewing engineering students.

As someone with a CE/EE degree, I don't really agree.

Like you said, that background does have a lot of benefits. But the downside is that a CE grad typically spends less time doing "software" work than a CS grad. When a CE student is taking courses on circuit design, FPGAs, and CPU architectures, a CS student might be taking courses about databases and concurrency. I don't think I touched SQL or a multithreaded program in a university course. Those were all "high level" things that CS students focused on.

This isn't meant as a knock on CE grads -- I just don't think it's wise to suggest them as the solution to OP's problem since they have their own set of "blind spots" to deal with.

I don't know much about Circle and hold no resentment towards them, but this sounds very much like a "them" problem.

If you're operating a business that requires millions or billions of dollars sitting in a bank account, you can't plead ignorance around FDIC insurance and claim that you're just a small business trying to scrape by. Your business is open to a big risk, and there are well understood techniques for managing that risk. If you're a disruptive company who's trying to change the world and you don't fit into traditional finance, you find a creative way to deal with the risk. But if you _do nothing_ and keep all your money in a bank hoping they don't collapse, sorry, but that's accepting the risk.

I don't see this is a systemic failure. The system is set up to protect individuals and small businesses, with the expectation that larger companies can pay people to manage these risks. If Circle's CFO and finance team couldn't come up with a better solution than parking all their money at SVB, I'd argue it's a sign of Circle not being a viable business rather than a sign of some fundamental flaw with the banking system.

It seems like most people have a "never again" Airbnb story at this point.

I once rented a condo in a city on the east coast, and the rules mentioned that the kitchen is available but to avoid cooking anything "crazy". No further details were provided. My partner and I boiled two lobsters and sauteed a few scallops, thinking that wasn't a "crazy" thing to cook in a rental by the Atlantic ocean.

A few weeks later (one day after the review window closed), we got a DM from the owner telling us that they found the lobster shells in the garbage, and that us boiling the two lobsters was in violation of the rules. Supposedly, the odor from our cooking triggered their incredibly acute seafood allergy to the point where they could no longer live in their own condo, and they filed a complaint with Airbnb seeking $500+ in damages. There was, of course, no mention of this seafood allergy anywhere in the listing or in the rules regarding cooking.

Airbnb threw away the claim, but in an attempt to mollify the host, they allowed them to write a negative review of me (after the review window had closed) and how I permanently ruined their condo. Thankfully I don't care very much about having a spotless reputation of Airbnb anymore, but it's crazy to me that Airbnb did anything to appease someone who basically tried to extort another one of their users through their platform.

I've never dug deep into this, but the normal argument is that it's possible to saturate a 100Mbps link with a single 4K Blu-ray stream. Even if most people will never hit that limit, it would be nice for a top of the line 4K TV to support "normal" (for some media-savvy folks) 4K streams.

But that's not a very compelling argument on its own, since the Ethernet link is just one link in the chain. Having a gigabit port doesn't help much if the TV can't handle decoding video at those bitrates in real time. It's definitely possible that TV manufacturers choose 100Mbps ports because they know the TV can't deal with huge streams for other reasons.

It's an interesting situation for the manufacturers. Even if 99.9% of buyers will never see streams above 100Mbps, and even if that other 0.1% can't effectively use them, it might be worth it to bump the port to gigabit since complaints about 100Mbps ports come up so often in reviews and in online discussions. Maybe throwing in a borderline useless gigabit port would generate enough sales to justify the marginal BOM cost increase.

I dunno. Sometimes it’s just Hanlon’s Razor.

In some industries (e.g. defense contracting), getting a concrete answer for where you can and can’t store certain information can be a nightmare. And often times there isn’t even a definitive answer.

So from a risk perspective, it’s easier to have a policy of minimizing the things you write down in emails and documents. You obviously need to write some things down and need a policy for those things, but if you’re just conveying a few paragraphs of information, a brief face-to-face conversation is much lower risk than writing the same notes down in SharePoint somewhere and hoping that you don’t screw up the security markings.

I guess I’ve never seen this as an official directive from management, but it’s been the reality at a few places where I’ve worked and it was never because anything shady was going on.

Those examples aren’t super convincing to me. At least not yet.

Rust was created at Mozilla to help with browser engine development, so it’s not totally shocking that it’s in Firefox.

Rust is in the Linux kernel in the sense that its build system can compile interoperable Rust code. But the kernel is big — it’s 30 years of C code written by thousands of contributors which receives dozens of patches (in C) per day. Obviously “Rust in the kernel” has to start somewhere, but as of today, it’s really only relevant to Rust people who evangelize it. A kernel developer who doesn’t read HN would probably have no idea that Rust support was added.

Going back to the OP, the claim that C++ is “becoming a legacy language” is…bold. IMO it’s a ridiculous comment until large C/C++ projects (e.g. Linux, LLVM, Postgres/SQLite, big AI/ML toolkits) are mostly rewritten in Rust or overtaken in market share by alternatives written in Rust. If all of the biggest systems software projects in the world are still mostly written in C/C++ and still receive almost all of their contributions in C/C++, claiming that Rust is bumping those languages to some “legacy” tier is ridiculous. Things might go that way in the future, but we definitely aren’t there yet.

> Hedge Funds seem to want to move Alphabet to that more predictable pattern

Or the hedge funds feel like this has already happened due to their massive size and bloated management. Maybe they think that Google is beyond the point of meaningful growth in new areas (relative to their ad revenue), so they should start operating like a boring corporation instead of throwing insane salaries at everyone like magic beans that will sprout into new areas of growth.

This isn't necessarily hedge funds pushing for Google to change into something they aren't. Maybe they're just pushing for Google to accept the reality of the situation they put themselves in.

I don't necessarily agree with that perspective, but I don't think it's totally unreasonable.

> compared to 5% with fiat money

Sorry, what?

I don't think the breaker is really relevant here. Unless you've been impaled by a spike, it's impossible to draw 15A of current through your body from a 120V or 240V circuit. At those voltages, there's really no difference (to you) between shocks from circuits with or without a 15A breaker.

I guess there is a asterisk here if you're also shorting something much more conductive than yourself, since the breaker might cut power before you'd naturally let go and break yourself from the circuit. But that seems like a pretty unlikely situation for most home shocks.

This might be a bit pedantic, but “Linux” in the general sense doesn’t use the outdated security model you described. You’re basically comparing discretionary access control (e.g. user/group permissions) with mandatory access control (e.g. SELinux), both of which Linux happily supports…

…but the usage of MAC in Linux is so awkward that it might as well not exist, since the majority of distributions, packages and users ignore it completely to avoid all the headaches that come with it.

It’s tricky. It would be nice if the maintainers of big distributions/packages took MAC seriously and defaulted to restrictive SELinux policies or whatever, but history has shown this to be _very_ brittle and annoying for users. That’s why you see this stuff enabled in iOS and Android but not general Linux distributions — it’s much easier to lock things down with MAC when you’re developing a singular OS from scratch with apps that run in a sandboxed environment that’s isolated from the “system”. But if you’re maintaining something like python or pip, it’s basically impossible to do that.

I don't really know if there's precedence here.

Normally, to burn billions of dollars, you need to be an executive in a big, established corporation that has controls in place to avoid that sort of thing from happening. It's much harder to claim negligence if you conveniently found a way to sidestep all of that in some sophisticated manner.

FTX is kinda different. With crypto in general, you have relatively new, private companies operating in a space with almost no regulation, getting millions/billions of dollars thrown at them by VCs and customers in a short period of time. It would be possible for a software bug to burn money at an unprecedented rate in a crypto company when compared to a big established bank or something.

Even though that is possible, I can't imagine that argument holding up for SBF. I think it'll be tough to buy SBF claim he's a simple startup founder who got in over his head when lawyers present stuff like FTX's corporate structure. But IANAL and all that, so it'll be interesting to see how this plays out.

I guess it depends on how you look at the the percentages.

Lots of people _use_ Apple’s developer tools, Google Chrome and other Google products. But in each of those cases, I believe the actual group of people directly dealing with C++ and Clang are small relative to the global C/C++ developer population. Android has a strong argument since Google can force the hands of OEMs. I don’t see how the size of Chrome’s user base will bring about an LLVM monoculture if 99.999% of C++ developers on earth never build Chrome themselves.

The majority of electronic devices on earth have (non-Android) firmware or software written in C/C++, written by people all over the world who don’t work for Google, Apple or anyone you’d even consider a tech company. You will never hear about these projects on HN because they’re closed-source, proprietary and (frankly) boring. But almost all of those projects use whatever toolchain their vendor provides, and more often than not (in my experience), thats GCC.

Like I said, I don’t have any numbers to back this up. I’m not claiming that GCC reigns supreme and that LLVM is irrelevant outside of academia. I’m just saying that if you’re really concerned about LLVM _support_ in the kernel leading to an LLVM monoculture, you might not understand how widely used GCC is in “boring” tech.

[edit] Adding to this, I guess it also depends on how you view a “monoculture” w.r.t compilers. I could imagine a not-too-distant future where LLVM gets the vast majority of research effort, and you see cool new optimizations brought into it while GCC stagnates. We’re arguably already there. But I don’t see that driving thousands of low-margin hardware OEMs to switch over from GCC to LLVM. Maybe that will happen one day, but I think we’re pretty far away from that.

The illusion of a monoculture disappears if you zoom out a bit.

Even if clang was a "first-class citizen" compiler for the kernel and was picked up by some big distros, there's an absolutely gigantic market of companies designing and building embedded systems around GCC. There already is a LLVM/Clang monoculture in some areas (e.g. research, "modern" C++ shops), but while I don't have the numbers or anything, I'd imagine that those fields make up a very small percentage of worldwide C/C++ developers. A lot of those boring embedded systems companies have low margins and don't think particularly highly of software developers, so they'd never consider refactoring all of their tooling and projects to use clang unless they absolutely had to.

If the kernel _dropped_ support for GCC, you might see an actual monoculture develop. But I don't see the kernel _supporting_ GCC, or particular distros choosing to build their kernel with it, making any real dent in the huge market share (for lack of a better term) that GCC has built up. It might seem that way if you read HN and talk to people working in SV, but GCC is still pretty ubiquitous.

I used to work for a defense contractor where layoffs were pretty regular. If the company wasn't winning new contracts, they couldn't afford to keep paying all the staff. It's a pretty simple arrangement, and when layoffs happened, you didn't expect any heartfelt message from leadership about how unexpected it was and how hard they tried to avoid it. It's just the reality of that business and everyone knew that.

In a way, most tech companies are similar. The main thing they try to demonstrate to investors is growth. One aspect of this is hiring as many people as possible when times are good, knowing full well that when the market has a downturn, they'll be overstaffed and forced to lay people off. This seems to be how tech companies work, and investors seem to prefer for tech companies to be run this way. Mass layoffs are pretty much inevitable unless the market stays rosy forever.

So it's a bit patronizing to see a CEO write about how hard of a decision it was, or how they really tried to avoid this at all costs. They might not have predicted COVID, but they absolutely knew they were steering the ship in a direction where this was going to happen eventually.

To be fair, the messaging in this Plaid announcement is about as good as you can do IMO. They chose to hire at a rate that is only sustainable in an environment of infinite growth and they now have to reconcile with that. There isn't much mention of how heartbreaking this for the CEO, how much they love every member of the Plaid family, or how this is an absolute last resort they tried to avoid at all costs. It's just the result of how they chose to run the business. I think that's about all you can really say.

> Yes, I could restrict them from accessing the internet, put them behind a VLAN or VPN etc., but it's a hassle

Even if you find goldilocks IoT devices with completely open hardware/firmware/software and no backdoors, if they’re accessible from the internet, you’re still on the hook for maintaining their security forever. To me, monitoring and patching vulnerabilities for a bunch of different IoT devices is a _much_ bigger hassle than setting up a few VLANs.

So if you’re going to isolate the devices regardless, you shouldn’t really care if they’re running firmware written in China with a bunch of backdoors.

If Google stock were really worthless, someone could buy all of it for pennies and do whatever they want with the company. Owning and controlling a company with $80B yearly profits isn’t worth anything to you?

A single Google share isn’t really worth anything on its own. But its value is tied to the collective value of _all_ Google shares, which _are_ worth something.

There's a difference between saying "I could bang that out in a weekend and replace the whole department" and recognizing that 3,000 people supporting a relatively small feature is a sign of bloat in an organization. Surely there's _some_ point where the headcount becomes a sign of a problem -- would it be okay to make OP's comment if 100,000 people were working that feature?

I agree with your general point that a "software team" in a big org requires a lot more people than just engineers developing new features, and that the headcount doesn't necessarily scale linearly. That doesn't change the fact that in a normal business, if 3,000 full-time staff (support staff and all) are working on something, it's probably something pretty big that generates enough revenue or has enough growth potential to justify that cost. Even if a team is working hard and "doing stuff", they can still be grossly overstaffed.

Yeah. As an individual, if you stop tipping, a large chunk of (North American) society will think you’re a cheap asshole who’s disrespecting your server and won’t care that you’re taking a stance against a larger issue.

There’s nothing wrong with ignoring those people. But I think the average person cares much more about social norms and being judged by others than the people suggesting to just stop tipping.

Engineering programs do include a required ethics class. But with a cynical lens, it's only required because the bodies that license engineers and permit them to practice require that course in order for a school's degrees to be accredited. Once an engineering graduate is licensed and practicing, they're on the hook to follow a standard of practice that includes ethics. If they violate that, their licensing body has the legal teeth to punish them in a variety of ways (e.g. fines, removing their license). Also, employers who do engineering work have to agree to a similar deal with the licensing body. If they force engineers to act unethically, those engineers can report them to the licensing body who also has the legal teeth to go after them in a variety of ways. It's not a pretty system but it generally does an okay job.

The ethics course itself is a very small piece of the puzzle. Even if every software engineer had to take an ethics course, there's still a huge power imbalance between the average engineer and their employer. Ethics are great and all, but without a legally backed standard of practice to protect those engineers, widespread violations are more or less inevitable. You can stand up and refuse to do work because it goes against what you learned in your ethics class, but your employer can just find someone who doesn't feel as strongly about that. That still happens in traditional engineering fields, but there's at least a legal/regulatory framework in place to discourage it.

Some jurisdictions "solve" this by lumping software engineering in with other disciplines and making the same licensing bodies deal with it. This is also a big mess. Those bodies are normally led by "traditional" engineers who barely understand software, their standards/legislation were written before software-specific issues (e.g. mass surveillance) were relevant, and their processes don't move fast enough to deal with a rapidly changing field like software engineering. It may be possible to fix all this or create similar organizations and legislation specific to software, but it's not trivial.

I this overinflates the importance of the HN crowd a bit.

Yeah, a lot of software engineering types switched to MBPs because the OS isn't a steaming pile of garbage and it reliably works with the hardware. The former can't be said for Windows these days and the latter is generally hit-or-miss with Linux.

But I wouldn't be surprised if that's a rounding error when you're talking Macs doubling or tripling their market share. I'd imagine most people walking into an Apple Store in their local mall and buying a Mac with Apple Pay on their iPhone don't really know or care about the telemetry added in Windows 10. I still think Apple deserves the vast majority of the credit for the success of Mac.

Yeah, TFA talks about TM having a monopoly and their dynamic pricing, but it never really explains why those two things are related or why either leads to higher ticket prices.

In an ideal world, TM wouldn't have a monopoly on ticketing for large venues, and artists wouldn't be forced to work with them. Artists and venues could still charge whatever "dynamic" price the market will bear, but competition in the ticket space would hopefully push down the cut that the ticket distributor takes. I'd imagine this is why artists are generally unhappy with TM's monopoly, since they don't have much leverage here once they're booking venues of a certain size.

But TM's monopoly is here regardless of how they price their tickets. And in a world with that monopoly, TM's dynamic pricing model benefits artists more than the previous model, even if it isn't the best possible arrangement for them.

I guess the main argument is that anything a monopoly does to increase its profits is bad. That's fair -- TM makes more money from this, and they'll probably turn around and use that money to strengthen their position (e.g. sign contracts with more venues), making it harder for any competition to challenge their monopoly. But that's a really broad issue. Dynamic pricing itself seems...fine

Before Unicode, everyone who came up with a character encoding scheme probably thought their system was good enough for any reasonable use-case. But they all had limitations that made them inadequate for things less obscure than representing some dead Mongolian language.

It would be nice if we could come up with some magical system that optimally encodes all the text that "matters" and ignores everything else, but history has shown that to be very hard. So we're left with Unicode, which takes the approach of giving us (effectively) infinite code points to represent characters, with (effectively) infinite ways to visually represent them. That does lead to a bunch of "unnecessary" baggage and headaches, but it also solves a bunch of real problems that you probably don't know exist.

Unicode is a pain in the ass, but it's a solution to a very hard problem. You can feel free to design your own solution, but you'll probably run head-first into all the problems Unicode was trying to solve from 40 years ago.

The defense industry really is the GOAT when it comes to slide decks.

Nothing gets the creative juices flowing like sitting through an 8 hour presentation of a deck with 200 slides, which are really just 10 different slide decks from 10 different departments stitched together, mostly containing quotes copied from actual design documents and pasted into bullet lists