Hacker News new | past | comments | ask | show | jobs | submit | brey's comments login

I work at Featurespace - we stop fraud, scams, money laundering and other financial crimes.

We build software that runs real-time machine learning models at scale, deep in the financial 'rails' that move money around, and we license it to banks and other financial institutions.

A surprisingly large number of my colleagues are here because of similar reasons - we like making a positive societal contribution.

We're hiring!


'permissible' isn't quite the point ... if it makes the jury think you're lying, maybe it isn't the best strategy.


1. The jury should not base their decision on their belief whether either side is lying.

2. The defence is expected to lie, and if the prosecution cannot prove that every single one of the defence's arguments are lies, then the jury cannot convict beyond reasonable doubt.

3. The jury should assume that the prosecution is lying by default, and acquit if the prosecution does not convince them otherwise.


> 2. The defence is expected to lie

The defence is expressly prohibited from lying. Lawyers have a so called duty of candor [1] outlining this. Defendants testify under oath to make this clear to them. Defence attorneys must disclose to the court if their client lies to the court (and they can't convince their client to voluntarily disclose it instead) [2].

That doesn't mean people are expected to take defendants at their word during trial, juries are allowed to decide they think that someone was lying, but they aren't expected to lie.

[1] https://definitions.uslegal.com/d/duty-of-candor/

[2] https://www.eiglarshlaw.com/when-clients-liewhat-must-you-do...


The jury can decide that any given testimony is a lie and weight it accordingly.


Defense theories are not testimony and, ideally, should not be considered in the evaluation of testimony.

(In practice, humans don't consistently compartmentalize well enough to reliably avoid this, though.)


"defense theories" are going to have evidence associated with them. At that point my point applies.


Certainly, but is there some other penalty for what might be construed as contemptuous and disreputable behavior?


It might be perjury


The laws of physics permit (physically allow) me to punch someone in the face. The laws of my country say if I do that, there will be consequences.

This is all about the level of abstraction

The ‘laws of physics’ in a game may allow you to do unintended things, it’s a complex system. Doesn’t mean that it’s OK at a higher abstraction.


That does seem the better outcome - there’s no downside in being lenient here.

> I did a quick scan of the Alexa Top 1 Million list. Currently around 0,06 % are affected

Only affects a small minority of mailservers, and even then only 0.06% of domains.


I have, it's worth getting, it definitely scratches the same 'must ... optimise ... better ...' itches.

It's early access but very playable and feature complete, but it does feel less polished than factorio (obviously can't compare to an 8 year development effort!)

Satisfactory is another great play for fans of the genre.

Both games are 3D, and both use the additional dimension well. You can play them fine just like factorio (I did the first runthrough) and treat 3D as eye candy, but you'll do better if you 'cut with the grain' and learn how to build 3D factories.


> in an enclosure of chrome steel uprights, mounted on a wooden base, with a handle at each end

That sounds so much better than “built on an upturned coffee table” ;-)

But I jest - it’s very cool. I love the physicality - makes it feel much more real than 3D graphs represented on a screen.


> what is the best calculation to make when trading off code quality vs features?

> do most YC startups write tests and try to write cleanish code in V1 or does none of this matter?

It only matters when bad code hurts your overall business velocity - what that means, only you can answer.

Nobody's writing tests for their purist aethestics, they're there to let you go faster - but there's an up-front cost you have to pay for them. Sometimes that's worth paying, sometimes the land grab is more important.

There's no single answer to this question.


Tend to agree. Leadership needs to send strong, clear signals about quality and acknowledge existence of potential technical debt well before the team starts feeling crushed by it.


a few principles I've found helpful:

There are no coincidences, unless proven otherwise.

If something smells wrong, it probably is. Trust your gut.

Make sure you're building the right thing, before you build the thing right.

Don't be clever. Elegant one-liners that make you feel like a genius when writing it are probably not very maintainable.

The second best piece of code is the one you just deleted. The best one is the one you didn't write in the first place.

Plan to fail, and gracefully degrade.


I've been through deals with large financial institutions that have taken 2-3 years from an initial incredibly positive demo and PoC and strong buying signals, through to a signed contract.

IMO going through that successfully is also sending a signal that you have sufficient endurance - there's a large risk for a corporate to sign up for a long contract with a startup, they don't know how long you're going to be in business for. If the startup doesn't have the appetite to spend 2-3 years to get a contract over the line, then they aren't going to be a stable partner for the long term.

You need to also have sufficient numbers of small/medium scale deals so you're not 100% relying on elephant hunting.


Yes, I'd be interested. We're evaluating Slack, MS Teams and Mattermost as a successor to Hipchat.

Something to move the needle commercially in favour of on-premise would be helpful in that evaluation.


Not sure about good on prem products, but if you want to broaden the scope - there are a couple of others including Glip, Flock, and Twist which I have come across in some reviews, including the PC Mag reviews. Have tried out Flock and Twist, specifically- you might want to add these to your consideration set


You will be soon able to evaluate Nayego as well: https://nayego.net/ you can subscribe if you want to see the preview.

Nayego is an open source and open standard team chat, that is federated/distributed/decentralised.


Where's the source? nayego.net doesn't have any links.


I'm pretty sure it's spam.

I found a link, but it only has a README

https://github.com/Nayego/Nayego-client


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

Search: