sillybov3456
sillybov3456 on Hacker News
Respectfully, it's not. Choosing a bank is an aspect of risk management, the act of throwing all your money into whatever thing that calls itself a bank and is most convenient is not risk management, it's risky behavior.
Risk management would be asking the question "should I be putting all my eggs in a basket that seems very tied to the tech economy / northern California real estate market / low interest rates?". Diversification would be trying to get the money you use to pay your tech workers invested in something as far away from tech as possible.
Not when it's a very young very tech focused bank preaching the gospel of "innovation". There is a reason the old banks that survive and are still around tend to be of a more conservative disposition.
They didn't have to open an account with SVB, they could have gone with JP Morgan or another reputable but traditional financial institition. Ya know, a household name of some sort. Seems like a bunch of folks got suckered by clever "startup focused" advertising and convenience features on the part of SVB. Banking is an old industry, something about how the founders mind works led them down the path of believing the same sort of logic must apply to banking and so they decided to go with the new kid on the block. At least personally, hearing about something "innovative" in the context of finance is a huge red flag.
Your local pizza delivery wouldn't be caught out like this but somehow highly educated startup founders all were.
In other words, I'm not sure regulatory capture has much to do with this situation.
It depends, if online only I would honestly just go with a brokerage like others suggested. If you need more traditional banking services then JP Morgan/Chase is the largest and also probably the most stable and reputable, but they do have a minimum balance for their checking accounts. They have an aura that surrounds them due to being very old and surviving the depression. Doesn't mean they would survive a depression today, but it's good advertising at least.
Local credit unions are an option but your mileage will vary. Often membership is not open to the public.
I think based on the parent posts choice to go with the "who is your customer" definition and the fact that we intuitively think of RabbitMQ as some sort of systems program, it probably fits the modern definition of systems program that we all kind of agree with but do not necessarily put into words.
I don't think RabbitMQ being written in a "non systems language" is relevant. Its a systems program even if it was written in shell (if it was it might be a bad systems program, but a systems program nonetheless because of it's intended customers and use case).
This is the only sensible answer. I disagree with the old-school definition in which systems programming is necessarily concerned with hardware imposed resource constraints, I think that definition lost it's relevance somewhere between 1990-2010. If it's just resource constraints, then the majority of what we would think of as systems programming (like core operating system utilities and whatnot) arent really systems programming anymore since those constraints have largely disappeared (and implementations have in some cases stopped caring about the now not very important constraints as a result).
So it really comes down to who your customers are. If your primary customers are other programmers and they are using your program programmatically, then you are most likely doing some kind of systems programming.
That's the only definition that makes sense and maintains a (reasonable if not somewhat arbitrary) distinction between systems and applications once you account for many systems programming tasks no longer being constrained all that severely by hardware, and we recognize that many applications programs have grown and fit the definition of a systems implementation in terms of complexity and number of interacting pieces (another commonly cited definition of systems programming that no longer makes sense. This would necessarily mean that something like Amazon.com is a systems program, which nobody would agree with intuitively).
The value in maintaining the distinction into the present day is mostly in the way it sheds light on various user interface and portability concerns. As in, as a systems programmer must take a very different approach to user experience (since your users are either other programmers of programs) compared to applications programming. A graphical user interface on a web portal is probably not a good idea (at least as the base/primary ui) for a program that is used by other programs and programmers, but it may be a great idea for an application. On the other hand, CLIs make it easy for other programs and programmers to compose functionality with other programs and modules, and so a CLI being the primary interface is a good (but maybe not quite sufficient) indicator that you are probably working with a systems program.
The problem isn't insuring the losses, that they can do. The problem is will you even be able to buy anything after the chaos if a systemically important financial institution goes under? The banks that hold the most ordinary customer deposits aren't like Lehman Brothers and the fallout from one of them going under would be catastrophic on a level far beyond something like 2008.
FDIC was invented for the great depression when banks were not as large or concentrated, nor were they as globally connected and intertwined with day to day business. The reality is that FDIC is far from being sufficient insurance to calm down a collapsing market, that's why we had to do bailouts in 2008, because of what was coming down the road in that regard if the contagion were to spread further.
FDIC insurance is similar in the sense that if the feds ever have to say "don't worry that JP Morgan or <other large consumer facing bank> is going under, most of you will be covered within the FDIC limit", then we're fucked in so many other ways it doesn't matter. That is after all why we invented the term "systemically important".
I absolutely agree not to get into security and try to stick a little closer to programming, with the same caveat that if you are doing some programming for a security company then maybe it would be a little better.
You aren't alone in not liking the cloud. At the end of the day it's just outsourcing.
That's super interesting, and you're definitely right about the internet thing. I suppose our network guys must have some way to see if a change will propagate beyond a particular interface?
Right, the thing about root causes is that you can always keep digging. For instance why was an incomplete snapshot shared? And then the why for that why, and on and on until you reach the singularity at the beginning of the universe, which can logically be the only real root cause of anything. Root cause just means whatever is enough to make your boss satisfied.
That isn't really how production networks work in my uneducated opinion. If they are connected to the production network then they are the production network, and the level of isolation required to make that not the case would be so extreme as to make things potentially more unreliable.
Others can correct me if I'm wrong about this. All I know is that the production network where I work is not air gapped in the way that would be required to truthfully consider testing networks a non production environment, so non prod changes typically wind up in front of the change review board anyway.
Ask your own sites network engineers and see if they have similar constraints because I would be interested to hear more perspectives on that.
One other thing I will say is that the abstractions of "config plane" and "data plane" and "control plane" don't really exist on real physical systems. That is mostly an abstraction created for applications people, those systems are not going to be totally blocked from interacting with eachother, they kind of have to. So if any of your "planes" are shared with production it is a production environment.
The other point of view is that the industry would have been entirely off shored. I think this is particularly a concern in tech, where US workers are notably spoiled even in comparison to the rest of the US. That wasn't the case with the auto workers to the same extent and so people were more sympathetic.
I'd imagine everybody in tech gets told to fuck off pretty rudely if it ever gets to the point of bailouts, so the good news is that your concern is unfounded.
Atlassian is competing with GitHub and you can't understand why they would ban it?
Do you run GitHub enterprise on prem? I'm curious because I'm always surprised when I see companies that haven't banned Microsoft server GitHub. Seems like a massive risk.
It also massively reduces their potential customer base in all the industries that are typically more resilient to recession.
How would you know they are a bootcamp person? Technically I'm a "bootcamp person" since I went to school for EE and not CS (so I'm mostly self taught when it comes to programming anything that isn't C), but that isn't something you would ever know about me without asking. I would imagine there are a ton of people in the industry with similar stories.
Bootcamp people being easily noticeable would seem to require them to be noticeably terrible in some way. I'm not sure you break into tech that way. My projects and technical interview skills were way ahead of the average CS graduate at the time precisely because I was a "bootcamp person" and couldn't rely on the degree.
I'm sorry but I'm not entirely sure who or what you are responding to with this. Could you explain a little bit of the context so that we can understand the point that is being made?
I think it can but I wouldn't call it a miracle. The "boomer bulge" in the workforce is in the process of entering retirement en masse. The generations replacing them are smaller. This will contribute to higher inflation (lots of money that was sitting in real estate and 401ks being withdrawn to compete over a limited supply of basic goods and services like healthcare), and also to lower unemployment.
It doesn't necessarily mean we are experiencing a miracle and will have higher living standards, I promise it is quite possible for a nation to banish unemployment but still have a majority of people struggling to get by.
That being said, I think we haven't seen the full effect of higher interest rates yet, we are just getting started with that.
Its peak hacker news to come up with a term like "legacy industry".
This is all based on a myth though, primarily the myth that "only COBOL" developers are a common thing (people believe this for COBOL even though it's never really been a thing for other languages, wasn't even ever really a thing on mainframes, increasingly they are majority Java).
What I'm getting at is that you aren't going to find a ton of jobs where you are working on COBOL but somehow avoiding Java when the two are connected at the hip on the platforms they are used on.