Joe8Bit
If it were "just" static pages, served the same to everyone, then it's pretty straightforward to implement even at the >300m users scale Netflix operates at. If you need to serve >300m _different_ pages, each built in real-time with a high-bar p95 SLO then I can see it getting complicated pretty quickly in a way that could conceivably justify this level of "over engineering".
To be honest though, I know very little about this problem beyond my intuition, so someone could tell me the above is super easy!
> In my experience, “show me the data” is often a tactic employed by weak managers who don’t know how to hang as part of a design process.
I really don't understand how asking to see data and talk in facts, rather than opinions, is a bad thing? This take seems to be implying the "design process" is just a giant, strictly qualitative "appeal to authority" fallacy and anyone who doesn't "get it" is some kind of naive rube?
Instead a lot of motivating factors I've seen are about preventing various paths for "legitimate" data disclosure to third parties. For example, when data at rest is combined with additional requirements like "bring your own key" it means a subpoena or NSL needs to be served on the _first party who owns the data_ (as they need to provide the keys) and can't be served on just the cloud provider without the first party having at least visibility of it.
My memory's hazy, but I remember it becoming more and more complex to maintain as the web's security and performance model evolved, as you needed to manage and secure all of these disparate, discrete DOM trees in the same page context.
Wouldn't what you suggested just been "reinventing" frames/framesets if you added the ability to arbitrarily pull in templates via the network?
I've seen this "GC-less" Java in those use-cases quite a bit. From a conceptual design POV it's likely not the best approach, but there's a lot of sunk cost in that eco-system and a lot of trust and expertise where "Choosing a better language" is often several orders of magnitude more expensive.
This might be true for first party lender to first party debt buyer, but it often falls apart after that first step.
The article mentioned the chain of debt ownership and that, in my experience, is where contracts and supporting docs are lost. Once you're buying debt 3 or 4 steps removed from the primary lender the documentation becomes sparser and sparser, which is why as the article rightly said, most of these "last mile" agencies rely on people's ignorance and use a "spray and pray" strategy for debt collection.
My experience, from a large primary card issuer in the US, was that most of the major, reputable debt purchasing agencies would only buy primary debt portfolios that had _contractual guarantees_ about the accuracy of the supporting contracts and docs. They'd spend a lot of time and effort reviewing them, but they would in turn outright _refuse_ any such provisions when THEY sold their debt to smaller agencies!
I applaud the move either way, but stopping doing something that's 0.1% of your revenue vs something that is 25% are two very different things.
One of the most morally repugnant parts of the Western legal system is the creation of the labyrinthine corporate structures used to to protect the ship owners for any liability as part of their ships being broken.
Overall, my pricing has been about the same or 5-10% less per month.
It doesn't have the same "Click this button to add this third-party service to your dynos, with billing included" eco-system that Heroku has (had?) but my Heroku usage was pretty vanilla so it wasn't an issue for me.
That obviously isn't viable for all early businesses and even the ones it is viable for eventually need to hire engineering teams to build their products, but I love how much more accessible these tools have made shipping something basic.
This is also my experience for folks that live in NY.
The problem was people would constantly try to "steal" the number. Four or five times a year my phone would just stop working because someone had "persuaded" a call-centre worker at my provider to assign the number to a new SIM they could sell on eBay. Apparently people pay a LOT of money for vanity numbers.
No matter what additional "security locks" they put on my account it kept getting hijacked, so eventually I just got a new (much less interesting) number.
> Shared pain
I've worked in some orgs with very large monorepos (1000s of developers working in a single repo) and broadly have had positive experiences with them, but this 'shared pain' was by FAR the biggest drawback I experienced. When things went wrong with the monorepos they tended to go VERY wrong and effect EVERYONE. Multiple incidents of the monorepo just crushing productivity for 1000 person engineering orgs, for a period of time.
That's not to say I think monorepos are bad, it's 100% context dependent whether they make sense for your org in my experience, but I learned that the same tradeoffs you get with architectural monoliths/distributed systems often apply to multi/mono repos as well.
So any Russian military retaliation that occurred between Sweden announcing they intended to join NATO but before they officially did would, in effect, be an attack on the whole EU block. Which is tantamount to a direct attack on NATO.
Finally, Sweden has several bi-lateral defence agreements with countries like the UK and US. It's obviously not technically the same as being a NATO member, but many people in the Swedish defence establishment regard it as closely equivalent.
Also, the article does a good job of describing one side of clinical trial complexity, finding participants and getting them through the funnel, but there's a whole other source of complexity in clinical trials that mean you need massive global efforts: different global regulators have different criteria for 'approving' clinical trials. An indicative example, the Japanese regulator needs to see evidence that the drug was tested in Japan during a trial. They're one of _many_ national regulators that say that.
So even if you _could_ find all a trials participants in one country you likely wouldn't be able to get it approved by many national regulators.
There are 100% valid epidemiological reasons, but often these differing national rules are there for policy purposes outside of drug safety, for example, if you mandate trials need to take place in your country it provides a nice investment in biotech for your economy or by creating specific rules as a lever to control cost in your national healthcare system (e.g. NICE in the UK).
The amount of time passed is also something I've seen have an impact (e.g. if you had a DWI 20 years ago vs one 6 weeks ago)
If you have a criminal conviction it's unlikely you'll get through the screening process with a regulated business (like banking, insurance, pharma etc) due to some 'out of the hiring managers hands' constraints those industries have. I've seen exceptions to this in the past, where a senior manager strongly advocated for the exception, but it's _very_ rare.
I've worked with several security people with criminal convictions in the past at non-regulated, FAANG and FAANG-like tech companies. They also usually have policies in place to prevent hires with criminal convictions, but the exception process there is easier, particularly in security teams where these convictions are more likely to occur in strong candidates.
The biggest concentration of folks with backgrounds like yours have been at security consultancies, in my experience. Combined with the experience you mentioned with bounties, that would be the place I'd spend most time looking. You might still get rejected from some, for example those with customers that require criminal background checks for employees or security clearance you couldn't get, but there are still quite a large percentage where you could find work. Personally, I've had conversations with external consultancies who say things like "I know you require criminal records checks on all our employees, which we're happy to do, but I want you know >50% of my team will fail them".
A couple of other things:
- No matter where you work, with your background there might be some kind of 'restriction' placed on what you work on and/or how you work (e.g. can't work on project Type X or must work from Office Y). If you do get through a process, ask about this before joining, as it might have an impact on how much you'd enjoy the role.
- Be open about your background. You sound like you would do that anyway, but the more open you are the better, you don't want this to be a surprise to people. What you're looking for is a strong advocate on the hiring team, so building trusting relationships with people will be important.
Don't be too down on yourself, you might have made some bad decisions, but you sound like a talented professional. The criminal justice system exists for people to serve their punishment and then move on with their lives. There are companies that will be delighted to hire you because of your skills. Your road may be a little tougher than for others, but that doesn't mean you can't end up professionally happy, fulfilled and well compensated.
The complexity is usually compliance (eg KYB, sanctions checks, AML) and while payment processors have done a lot to reduce the time and complexity it can still be a long and painful process.
In my experience (I’m CTO at a payment network) technical integration is <10% the time for a merchant doing this kind of volume moving processors.
Finally, what you described has happened. A lot of payment processors have been heavily influenced by Stripe’s DX and align relatively closely, or at least closely enough to make transition easier. The challenge is that few even medium sized merchants just use the core ‘move money’ APIs that are ‘easily’ replaceable, they use things like reporting/reconciliation, anti-fraud and a host of other products that make up an ‘ecosystem’ of products that in combination is very hard to replace quickly.
As one example, they see a 'project' as one single set of cohesive documentation and they've built a UX/UI to facilitate that. This is perfectly fair but it means you need multiple projects for multiple documentation projects. In simple terms, everything in a project is intended to be 'one thing'.
Again, this might be fine but projects are so distinct and separated that it makes them really hard to maintain at scale (lots of repetition, no setting or customization sharing) and frankly, if you need the full customisation options you need to $400 a month for _each_ project.
This is a pretty unique to our model, so it's not really a criticism of readme, but it's the reason we've left. Archbee has some (not all) of the same limitations, but they don't charge us $400 a month for each project!
[0]: https://www.archbee.io/ [1]: https://readme.com/
It's so interesting from an incumbents internal POV (I saw it a few times during my time at McKinsey) as changing an organisations economics is often the unstoppable force that meets the immovable object of internal politics.
There's a really interesting ongoing example of this in the the UK as 'attacker' banks (e.g. Monzo, Starling) challenge the economics of incumbents. It's not quite the same, as these attackers are removing back-end cost (e.g. branch networks) from an already 'free' product (e.g. retail banking) but it's meant that big banks are looking at their balance sheets and seeing a set of gaping money pits that will require fundamental change in their operating models to be able to get rid of/compete with.
The challenge for AWS is one lots of incumbents have experienced: they created a market and it's economics and now they're being attacked by the next generation of market entrants who've structured their businesses to _specifically_ attack those economics.
What's interesting is that challenge can be a really big problem for incumbents, as those economics can form a core (very rigid) part of their operating model; it can make it VERY hard to address without fundamental (read: risky) change to a business. There aren't many examples of incumbent businesses doing it successfully, as it needs a kind of 'self-inflicted disruption' that's very hard to do in large organisations where politics and empire building can make it difficult.
If someone could do Managed NAT Gateway next I'd appreciate it!
[0]: https://dev.to/joe8bit/shipping-web-components-in-2020-2h54
Being able to do this in the CDN infra was pretty powerful.
I really like the design aesthethic this product encourages. There's so much charm and fun and eccentricity that's lost in a web where full-height responsive image backgrounds and blocky design frameworks are ubiquitous.
If this can help people express just a little bit of the wild creativity of things like early 2000's MySpace layouts or GeoCities pages I'll be a big fan!