Hacker Newsnew | past | comments | ask | show | jobs | submit | healsjnr1's commentslogin

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.


You can still look for suspicious activity without having any leverage over what legitimate merchants offer.


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.


I took this as “if you need more than one, plan for storing ANYTHING greater 1 or greater”

Meaning that if I need to store specifically 2 addresses per user, don’t force it at the data layer… just make it an easy to swap validation and no literal limits elsewhere


For display/view purposes, yes you need to decide what the likely option is. For model/type purposes, the decision to have a 1:1 relationship should be made only with great care, as the OP shows with the example of addresses.


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.


Very similar to me! Double degree in EE/IT, my first job out of uni was with a small company building gps chips. I actually spent a lot of time writing testing software. A couple of years in it went down the drain and I just naturally transitioned in to a software role (paid a lot better).


Funnily enough, there are quite a few Australian (and a few Kiwi) companies in the telematics space these days. Not sure how many of them are designing hardware from scratch though, versus off the shelf devices with custom firmware.


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.


Settlement is an active effort, but Tibet is an incredibly hostile region and the Han suffer from various health and fertility problems there.

The real solution to settlement would have to be Han intermarrying with Tibetans and raising their children as Han.


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.


Meetings take place across big tables, not with your faces taped to a cardboard box a foot away from each other to inspect your zits and boogers.

These are just digital calls that someone put poor representations of facial expressions alongside.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: