Please keep on blogging like you do withoutboats, your articles are a gem that I learn something new from every time.
Due to the work of you and others I do have hope it will all be better in future.
That said, might be my low standards due to many scars from my c++ background, but I’m already plenty happy with what we have today, so the fact that it will get even better in the next years is like cherry on the cake for me.
In defense of the person who wrote the HN title, I’ve seen KYC discussed in front-page articles roughly weekly for the past several years straight. I’ve learned about as much of it as I care to know (and more, honestly) from HN comments on 1st and 2nd page posts in that time. In just the past year, I can see that there have been about 1,000 comments mentioning KYC, and about 21 1st/2nd page posts that are explicitly about KYC (nearly 2 per month). Honestly I don't expect all of HN to know what KYC is, but I did expect most HN readers to have a general idea of what it is and why it's a huge pain for a small % of people (but very large number, 1% of the USA is still >3 million people).
Once you're familiar with it, your brain/eyes key onto "KYC" much more strongly than "know your customer". I might have missed the latter, but "KYC" in the title grabbed my attention instantly and reading the title made my heart jump a bit, because generally KYC means a pain in my ass, and even moreso for friends here on visa.
I have a Canadian friend visiting and staying with my girlfriend and I for a month or so. KYC causes actual headaches for her, to the point that she just decides not to get cellular service at all while she visits unless I get a pre-paid SIM under my name and hand it to her. When she pays for things like restaurants, I can't just Venmo/Paypal/Zelle/ApplePay her back on the spot, I have to withdraw cash at some point and coordinate giving it to her.
The general concept of "KYC" makes sense for some situations, but actual implementations really fucking suck for a lot of people. It's very scary to me to see it be required for more and more categories of services because of the way it's currently implemented.
But remembering the meaning of an acronym while scanning front page post titles without much context? No. My brain is pretty ruthless at evicting TLAs that are reasonably distant from my core areas of interest.
Maybe less important than knowing what it stands for is knowing what the implications are for businesses.
KYC is essentially about knowing who you are doing business with.
For individuals that's relatively easy, just the name and identification is required but typically there is the need to verify that the identification actually belongs to the person signing up. In banking that's why you typically have some video call with a verification provider.
For businesses it gets a lot more complex because it's not enough to know what business your client is, you also have to look through its corporate structure to figure out who the "ultimate beneficial owner" is. Essentially, who is actually controlling the business.
Now it got a lot easier recently as many countries now require businesses to file who their ultimate beneficial owners (UBOs) are.
The painful part is that it introduces friction in customer journeys as now you have to request the documentation.
In the financial industry you also have to run checks on those UBO's so that they are not known terrorists or sanctioned individuals but it seems this regulation is just that IaaS providers need to know who actually operates a server. Presumably for forensic analysis after a cyber attack.
No definitely not, I fully agree with you and others there. Just was a bit surprised by how many of you were there. But that’s okay. Days where we learn are rich days. The richest of them all.
I posted my comment because the linked proposal itself never uses the abbreviation "KYC" and none of the early comments spelled it out, so if (like me) you didn't already know what it means a quick Ctrl-F wouldn't help.
The proposal seems to use the term Customer Identification Program (CIP) instead, mentioning KYC (spelled out) only once, in the introduction:
> Section 1 of E.O. 13984 requires the Secretary to propose, for notice and comment, regulations that mandate that U.S. IaaS providers verify the identity of foreign persons that sign up for or maintain accounts that access or utilize U.S. IaaS providers' IaaS products or services (Accounts or Account)—that is, a know-your-customer program or Customer Identification Program (CIP).
A very significant percentage of us (I suspect a large majority) haven't really bothered with blockchain tech. Blockchain tech doesn't solve any problems that most of us actually need solving.
The use of bone char to filter cane sugar is interesting -- but something that I'm finding puzzling is that the above linked article specifically says that the bone char was used for sugar beet processing, but many other online sources consistently state that bone char is never used for sugar beet processing, only sugar cane processing. Did it used to be used for sugar beet processing but techniques changed?
Based on some reading, beet sugar refining is easier because of less impurities than cane sugar. So the modern technique for producing white beet sugar is to use vacuum evaporation to crystalize out the sugar out of beet juice leaving the impurities behind. Maybe before vacuum evaporation was invented beet sugar had to be undergo chemical processing similar to cane sugar to remove the impurities?
The deeper you plough this field, the more fruitful the findings.
No dead end in sight.
This may even take the cake.
Dark and heavy Belgian cake.
Cake of the dead, so to speak.
Can't tell if this is sarcastic or not but an entertaining example of everyone going straight to the comments (myself included). (for those who didn't see this is link is the same as the main post these comments are under).
“Where we going we don’t need docs”. That scares me… docs are among other things there to provide context and info for things not clear from why certain choices were made or not made… no way your AI is going to guess that I put that restriction because of an explicit request from product, despite it looking wrong…
Cofounder of Greptile here, good documentation is not going anywhere. What we do hate is going through bad documentation to find the tiny bit of information we need that is more often than not outdated to fit our needs. We are looking for ways to integrate information not explicitly written in code to understand codebases as well.
Indeed. Code describes how something is done, and possibly what is done, but it seldom fully describes why something is done, or why code exists in the first place.
The latter is typically the realm of requirements, design documentation, and possibly test plans.
Generating such documentation from code seems quite impossible, or at least wrong.
It is unfortunate that most open source software is lacking in such documentation, giving off bad signals to junior developers.
Edit: not to take away from the product being discussed here, which seems very useful! I am merely supporting the parent here.
> The latter is typically the realm of requirements, design documentation, and possibly test plans.
You forgot one of the biggest spots for "why" documentation... git commit messages, where the point is to say why you made this change. Maybe taking into account the commit messages around the code in question would help.
Yep... and the why of that message is apparent and makes perfect sense for the first commit. If you only ever start projects and never work on them again, that is all you need.
This is a great point, and something we think about. I think to an extent a super smart version of our product could infer intent from the code but there would be definitely something amiss if the author's intent was just never available.
Yep, agreed. As a founder of another YC company that's done a bunch of RAG on code and docs, the accuracy boost you get from having good docs makes a massive difference. You really do need a human interpreter to show you "how to use" a product.
I hope so! Unfortunately it will definitely be massively increasing the ratio of documentation to intentional documentation, so we'll have to see whether it increases documentation usability or not.
Imho programming is just a medium of reasoning. In that vein I find arguments like this odd.
As I believe they day there is no more need for humans to be involved in any programme , is the day there is no more need for any reasoning by humans. Not something that seems likely to me.
Then again this article comes from someone developing AIs… how could that not be lofty…
I learned to program because of games and honed a lot of it in the Games industry. Developing games, in house game engines, but also R&D work to push new accessories and other hardware to their limits in all kinds of ways.
It is an amazing industry to work at with people full of passion. I left that industry however about 7 years ago and never looked back. The pay as a developer there is really low, and crunching was at least then still a really “normal” thing. A shame though as developers in the game industry are often really highly skilled in their craft and know machines and all their layers very well.
Since I left I basically quadrupled my salary in these last years, and frankly my day to day work is easier and a lot less pressure…
I’m sure there are good games companies out there and I can imagine that work life balance is a lot better in 2024 then it used to be. Still, pretty sure the pay still sucks… if not I wouldn’t mind going back one day. Then again, don’t mind either way. I found that my true passion and drive is a lot more meta than games themselves.
There is a group of highly intelligent people who want to go into lucrative careers that won't pick CS in the EU, and they do in the US because of the pay.
I think it's pretty apparent that, while there is fantastic talent in the EU, the density isn't as high as it in in the US.
Might be of interest if Thread is of interest to you.