healsjnr1

The problem that seems to be being missed here is that while fraud is one reason Visa has say over what they accept, the much much much bigger issue is ATF, Money laundering and Sanctions.

Cards like the Freedom card will never fly with either the Networks or the Issuing Banks as these kinds of payment instruments are immediately used to wash illicit funds.

Visa's stance with Steam is bollocks, and it is another example of the monopoly they hold over payment processing. They shouldn't have the ability to impact a legit merchants catalogue.

But the idea that we can have a Freedom card also doesn't checkout. The less known about what the money is spent on the higher the risk. And cost of complying with Suspicious Activity Reports regulations is really high (as the costs of you breach the requirements), so any attempts to create / run this kind of thing often don't stack up.

I don't know that I completely follow on this comment, in particular how code reuse comes into it.

I think the biggest thing is about deciding whether you have one or many.

There are a lot of cases where having many doesn't just mean there is a list to show.

In a lot of cases, having many means you now need to choose "the right one" to show/edit/action whatever.

This brings up all sorts of complications beyond "just return a list instead of a single item".

Even if you don't end up building it out, I think it always a good thought experiment during the design phase to think about how things would behave if there where multiple of key resources, rather than just one.

Would it have implications elsewhere? Are there low cost alterations to the design that can be made now that make space / allow for this key resources to be a list later on? How hard would it these be to do later?

I'm many cases the conclusion might be it isn't worth it and that's the right choice (yagni applied judiciously), but every now and again this might highlight a valuable early stage change that would have cost a lot to make later on.

These patterns and practicee generally aren't intend for _you_ as the developer of the app right now.

They are intended for the poor shmuck 18 months later who has to work with a tangled mess of copy text stored in JS, server side yaml files and a CMS.

I've been that person at least 3-4 time now. I've waded through changes where having static strings got the UI would have simplified things immensely, and _none_ of these have had anything to do with internationalisation.

They have been far more prosiac (Legal request, product changes, rebranding, just general things like "where did this text under interest rate calculator come") but have still taken significantly longer than they should have.

When you are writing these apps it can feel like it's not that hard to go back later and pull out strings, just some grunt work.

But once you munge your code through three refactors and a framework change it becomes so much harder.

I think this is very relevant: https://fintechbusinessweekly.substack.com/p/with-blue-ridge...

TL;DR my understanding is that if you host a banking API you are going to get a lot of scrutiny on who your customers are.

And you can expect an increasing level of compliance regulations heading your way to help regulate and prevent the problems described in the parent.

Yep, this was my experience.

I graduated a double degree of EE and Comp Science. My final year thesis was a project with a local company integrating their custom designed GPRS module with a GPS module to demonstrate mobile tracking tech (it was 2003).

Because of the project I went straight into a hardware design job out of uni. I was designing boards for mobiles! Working on circuit design, prototyping PCBs, I was psyched!

Problem is the company was run _terribly_. 3 months in we all got put on 2 weeks forced leave and then given redundancies. Aside from dinner pretty terrible management, the economics of doing mobile hardware design in Australia just didn't stack up (we were the only company trying).

In the end there were probably 10:1 software jobs for every hardware job. Given my experience so far, I opted for software.

It has been great, I love software, but I sometimes wish I had lived somewhere that had a higher critical mass of EE work.

Yeah I was there around the same time.

The scale of the work being done to dilute the population is astounding.

We were there at Christmas time, having driven from Kathmandu. That trip was telling in itself: there was only one way to get a visa to do that trip, and all of the trips were run by a single Chinese government run tour agency.

Even with terrible roads, your can do the trip in 3 days of about 4 hours driving each. Instead they try and force most people into a 7 day tour. Luckily we got a driver we managed to haggle with and cut it down to 3 days.

Those who did the 7 days ended up staying in weird empty towns that had large hundred room hotels that were _completely_ empty, but also fully staffed.

The closer we got to Lhasa the more of this we saw. Huge infrastructure that appeared to serve no purpose other than to get people into the region.

This reminds if some time direct working on crypto toolkits.

Every few months, someone would always come up with a reason why "bad entropy" was the cause of a bug.

It never was, but it felt like a thing we had to go through, to get to the real cause.

You've also got to consider that this is putting _a lot_ of eggs in one basket.

Would 4-5 families really pool all their savings for 10 years to invest in one childs potential business?

Maybe. I think what is more likely is that 250k would represent a portion of the money a family could save and then put at risk. I would say this adds another order of magnitude on the earnings needed to be able to do this.

So I don't think it's worth quibbling over whether 50k or 100k is middle class. To do this I honestly think your parental income needs to be $1M+ a year.

> If code reviews aren't an expected part of the development process and there's pressure on delivering, it won't happen.

This hits at the heart of why I strongly agree with this post and think PRs and code reviews are ultimately destructive.

Reviews are going to get dropped _regardless_ of whether they are in the process or not. Pressure makes code reviews and quality worse, not better.

More than that, the need to "appear" to review is going to slow things down and can cause an exponential back up. I saw this happen about a mouth ago: 3 day release cycle got bogged down and then took _3 weeks_ to get a single release out.

Process goes out the window when pressure hits. You are then operating in foreign environment at the most critical point and your safety net of useless.

Your safety net when things need to go fast should be highly automated fast build and deploy, coupled with great test coverage, from unit to end to end.

The only exception might be if you work in highly regulated field where you legal required to have a very low Mean Time To Failure. In that case things move slow unless you are very well resources.

Otherwise (ie the majority of products) focus that effort on having a very low Mean Time to Resolve. If you absolutely need some form of quality assurance, Pair. Do continuous PRs and knowledge sharing rather than out of context after the fact reviews.

> Have you considered that... _you_ just like having your camera on, and like seeing other people?

Yes, I think this is the whole point here. This is a bidirectional relationship.

We all have biases, and for a lot of people wanting some physical concept of the person they are working with is one of them, so yeah, they might just like seeing your face.

It's your prerogative to turn it off, but there is a very real chance this will impact your relationship with other people.

The biggest change for me is that I now hide my self video 100% of the time. I can't see myself in an irl meeting, so I don't need to see myself online either.

Don't this kind of makes the whole problem go away.

I've got some direct personal experience in this one. A few key points from how I saw it play out inside:

- there was a lot of noise made about this by the bsafe crypto team when it was first implemented (anecdotal, but I trust the people that were there and the context below helps reinforce this). From what I heard there was clear communication that adding EC drbg to the toolkits the way nsa wanted was insecure.

- that happened before my time, but by the time I got there it was kind of an inside joke that EC drbg was an NSA backdoor (I think this was around 2010)

- the above was tempered by the fact that it was so horrendously slow, no one could imagine it being used

- even though RSA demanded it was the default RNG for the toolkit, the first part of documentation strongly suggested changing this default

- my memory is that this work on EC drbg funded development bsafe SSL toolkits. So while the money may have been relatively small, it opened up a new product for BSAFE

The smoking gun and the bit that made it really obvious that something was off about this came in its use as part of the TLS toolkits.

There was an explicit, but unexplained, requirement that the _first 20 bytes_ of random generated during the handshake were sent unencrypted as part of the handshake.

EAY led that crypto team, they knew their stuff and they knew that this was off and there was no legitimate reason for doing this.

My take: this team new what was happening and they made it clear to management. As a really the people who made the decision to take NSA money knew what it was and the implication and went ahead anyway.

As a foot note, when we did the cleanup on this we found that in some of the toolkits the way that the 20bytes was sent was flawed and would have meant that an attempted backdoor using this would have failed. Whether this was intentionally or not _shrug_.

But what are you fusing? If you want efficiency I guess you'll be using deuterium etc, of which we only have so much.

After that your efficiency declines until... Well you end up with fusion reactors that look like the sun. You also end up fusing all the mass that we need to live our lives on and make stuff out of.

If you don't think a civilisation could ever need the amount of energy that a Dyson sphere could provide, that's fine, we don't need one.

But if you imagine a civilisation that does need the energy a Dyson sphere can provide, then they make a lot of sense.

Points for most people are a zero sum or losing game.

I worked for a points loyalty program, and the customer always pays. The bank knows their market well, they know the redemption rate of points for different demographics and they set the annual fees on points earning cards appropriately.

For a small number of very diligent points hack customers, the bank loses money on this and the customer wins. For a larger proportion customers get back roughly what they paid in fees.

Then for the remainder the points eventually get written off or redeemed for value that is far lower than the fees they paid.

In my own anecdotal experience, I think it comes down to what the product you are working on needs, and how your team works.

Recently, I spent 3 years on Scala then switched jobs and spent 3 years in Ruby.

It was a shock to go back to dynamic languages, but after 3 months, I honestly couldn't tell which felt more productive or led to more stable high quality product.

In Ruby, we had all the issues people point out about dynamic languages, but the product didn't lean heavily on complex data structures or algorithms. We embraced complexity and failure and get good processes, designs and practices to deal with this.

In Scala, we had more rigour, but I also know I spent a lot of time on type design. Once things were sorted there was a lot of confidence in it, but generally, it took a lot longer to get there.

For certain systems that is absolutely worth it, for others (and in my case) it did feel like the evolution of the product meant this effort never really paid off.

I think the key point on this is `some use cases`.

For people who've spent a lot of time with ANT, you might be familiar with this article from its creator: https://web.archive.org/web/20041217023752///x180.net/Journa...

It was possible and even made sense to use XML as the format for a build tool, however, it got stretched way to far. The idea was applied in use cases that were less and less appropraite, as a result years later you end up with something that is unwieldy and doesn't make sense and, generally, thought of as "terrible".

There are use cases were JsonLogic might make a lot of sense, and for those that is great.

Generally, I'm sceptical as there is high risk of increasing couplings in a way that will make change much harder. This will be particularly true if it is applied to use cases that don't truly warrent this kind of solution.

Given the ease and severity of this I don't think being technical does anything for you.

I am grateful for the "upgrade now" message being pushed it. As a technical user I can't trust my skills and knowledge to truly keep me safe from this one.

That sounds amazing, sadly in a lot of organisations that isn't how it pans out.

Either the engagement with technology doesn't happen early enough, or when it does, the technology point of view isn't given the weight it deserves. The ideas have already caught and too many people are invested and have 'faith' it will all work out.

The crux of this is that many of those people who carry the weight in decision making don't actually carry any risk or responsibility for delivery. Given the scale of engineering and time to deliver, by the time it comes to fruition they've moved on, so they never experience accountability for ignoring the advice.

I can never find the source, but I'm certain I've seen a study that linked the tactile nature of books to stronger recall. Smell, texture, weight, cover art, all these things aid with placing the book in the context of your life which, supposedly, would help with recall.

If true, I can imagine with physical note books that roughly the same thing applies.

Thing is, at their heart, these are document editing tools. They don't actually need an on ongoing operational cost (yes, maintenance, but as a number of people point out you can take the jet brains approach and lock to versions).

The supposed benefit of my data being hosted is not a benefit to everyone. I already have multiple solutions to backup and sharing, I don't need another silo where my data lives. I don't need another vendor hosting arbitrary data which means I now can't use the product because the megacorp I work for won't let that through their legal.

Key point I was making above was that one off payment is an option and can be successful, we don't need to fall straight into the free vs subscription dichotomy.

Whether we agree with it or not, I think what is strange is how subscriptions models have become the norm.

There _is_ an alternative that isn't free and that is one off payments (rember when we used to buy software?). I happily pay in the order of $50 to $120 for one off payments, often locked to a version.

In many cases this is _more_ than I've ended up paying for subscriptions I've used, then abandoned after 6-12 months.

Just to be clear, it was the Ruby Princess in Australia.

Diamond Princess was the one in Japan.

You've really lost me with

> You can chose to get the virus

That wasn't your original argument and this does nothing to stop individual people getting the virus.

And the source code is worth nothing. The legal structure is already there to have the app changed without anyone being notified.

If they released an entire buildable set of source that I could use to build and install the app myself, maybe.

But that's about the only time I'd use this.

It is a combination of their previous behavior plus the behavior of the various agencies.

For example: https://www.theguardian.com/australia-news/2020/apr/23/gover...

The fact that law enforcement even asked for this would be to many people completely unacceptable.

It's why, despite their efforts to assuage people, so many people will not trust this government.

The backdoor legislation means that at a later date, after the code is released, they could request a backdoor to the app and _no one_ could talk about it. All the legal provisions are there.

I was thinking it was the Hardy-Ramanujan number [0] but I was off by one.

I'm assuming op is referring to the j- invariant [1], something I've only just discovered.

[0] https://en.wikipedia.org/wiki/1729_(number)

[1] https://en.wikipedia.org/wiki/J-invariant

> I hear this all the time, and it's almost always wrong. Engineers and businesses are always convinced they're special and don't fit the mold. That's rarely the case, and the money used on these initiatives was probably better spent elsewhere.

That seems like big statement given you have no context about the person making it.

I also work on a team that has built large potions of this intentionally and willingly. And the results have been great.

The reason is we don't hand off our business to a black box part way through our business process. We own it. Top to bottom.

This means when we change the products we sell, how we sell them and how we support them, we know the impact on our back office, reporting, invoicing and accounting systems. And vice versa

Yes owning the whole stack is expensive. But we also have parts of our company that rely on ERPs and other similar products.

I can tell you very clearly that our ability to develop products is an order of magnitude faster and cheaper than those relying on an ERP.

I've read that the tactile aspects of physical books help a lot. This is very anecdotal as I kind find the particular reference I was thinking of.

But personally I can recall the specific size, weight, smell and texture of physical books I've read. It adds context and helps distinguish books as independent physical entities which (I believe) helps with recall. On the other hand digital books have begun to blend together for me.

Again very anecdotal.

This point of view keeps coming up and it completely misses the point that _this already happens to every single women who has given up their career to look after children_.

This flexibility and cost you are talking about is borne entirely by them as they rearrange their lives and attempt to make things work while men continue with barely any disruption.

I'm my opinion this is deep, unintentional, structural sexism. It is the biggest issue I have with articles like this.

Stamping out overt workplace harassment and sexism is barely the beginning. There are deep structures in place that have benefited men like me for millennia.

These need to be considered not as complicated side issues but as the core barrier to achieving equity (as opposed to equality) in these fields.

But I think this is one of the points of the article: the human system are thoroughly broken and convoluted.

I've recently switched between banks and done just what you said: I went in to a branch knowing roughly what I wanted, but unsure exactly how to setup it up.

The end results was _months_ of back and forth. The agents in person or in call centres did not know answers to fairly simply questions (can I have an overdraft on an offset account) and were unable to answer questions about applications (my credit card application continually gave me notice online saying 'proof of other funds required', no one was able to tell me what this meant our what I had to provide).

These problems are not related to the deep legacy issues of interbank transfers and settlement or fraud.

They are failings in organisational design and management, information design, customer service design. I'd guess they are a symptom of continuous churn and restructuring, of flipping from in sourcing to outsourcing and back again.

They are all problems that are within their power to resolve (yes, at great cost )

I'm right there with you. At about 915, after stand up and coffee I have this spike of energy that gets me into work and makes me think 'tonight I'm going to put aside two hours for x'. Where x is side project, exercise, date night, whatever.

By 7:30pm that energy is a vague memory. Often the best I can manage is not falling asleep while I put them to bed.

People talk about crowding out the bad with the good: don't make time for things, just do them and let the world mold around what you love. In this stage of life though, the consequence of don't this can be massively damaging.

Kids this age are relentless, if you push hard for yourself it can be very hard to recover. But in line with other comments, I can feel the change coming. At 2 and 4, the sleep is better and their needs on us are becoming less.

I can see the light at the end of the tunnel and this helps me recognise that right now just isn't the time to push hard.

This assumes it was incompetence and not done intentionally.

My understanding is neither company is owning this data set and there is an assumption that it is a third company that has either legally or illegally obtained the data and is using it for their own services.

Another option is that the data was exfiltrated by a loose group of people who wanted this to be freely available on a random ip. Know the ip, get sick access to a trove of PII. No logins, no accounts, no trace.

Welcome to the early 90s internet.