POSWID* says that money laundering laws are intended mostly to keep the proles and other people within the system honest, while providing a clean and easy system for people with enough money or cachet to bypass it.
Those kinds of dependency chains look subject to a depth first search like Tarjan's strongly connected components algorithm, at least to my naive first pass reading. I've used it all over the place in e.g. analyzing foreign dependencies in database tables, or makefiles/rakefiles for task dependencies
It's always fun when someone asks an interview question that's even tangentially related and I get to go deep about the relative tradeoffs of a simpler algorithm like Tarjan's/Dijkstra's, over one of the more modern and faster but conceptually more challenging versions.
It's more the latter - as far as I am aware, eliminating specifically the human pathogenic mosquitoes will still leave plenty of other mosquito-adjacent species that can't or don't bite humans, or can't / don't transmit the critical diseases.
I think for the releasing-sterile-mosquitoes angle, it's actually more interesting to me to use some kind of molecular clock, I think I read about a genetic modification that resulted in a generation or two of fertile males, but then the Nth generation is sterile as a result of the molecular clock unwinding.
I don't know how much experience you have, and this also goes broadly for those looking but not commenting here, but if any of you would like a mentor, I'm happy to volunteer, contact info in the profile. Mentoring is, as far as I'm concerned, the most rewarding thing in the industry, and I want to do as much of it as I can handle.
Anyone else open to mentoring feel free to chime in, the more the better - mentoring is highly individualized.
Contrariwise, my unicomp model M has been going strong as a daily driver for at least 18 years. They may have lowered the quality more recently, and I'd recommend something in the cherry mx brown ballpark over it perhaps.
Many people swear by Unicomp, but I had that bad luck that I first paid for the thing, got the thing, and then read that as of recently, there had been problems. Problems with quality, problems with output. Then they went so quiet people thought they had gone out of business, then they resurfaced. By that time, I've had an original Model M and two different OG Model Fs. When I buy old stuff from eBay, at least I have my expectations calibrated to the fact that this shit is real old.
Your unit must have been a couple years older than mine, so it just might be of that more legendary quality. Yours is from at least 2008, right? You may even had got it before markets went bonkers!
> One thing however is a test suite is not usually exhaustive in the sense that any code that passes the tests is valid. Usually tests are more complimentary in nature.
Not in the world of AI - if your tests don't catch any known issues, the problem is the tests aren't comprehensive enough. There's no excuse at this point not to have an incredibly comprehensive test suite, to go with your other agent feedback loop constraints
>> if your tests don't catch any known issues, the problem is the tests aren't comprehensive enough.
Maybe I misunderstand but this seems like a fairly low bar in the test suite only covers existing bugs.
I'd argue that if you aren't going to look at the code you actually need a fully comprehensive test suite - in the sense that if the tests pass, the code is correct and you don't have to look at it at all. The problem is, that isn't very quick to create it seems. Of course, if there is a way to do it quickly in a way that is reproducible by others I'd love to hear about it.
I don't mean just bugs, I mean any known issues. I test infra, I test UI, I test binary protocols, you name it. There is certainly no fast way to do it, even with AI (an AI generated suite is better than nothing but not as good), and it's a serious investment, but it's worth it. Testing becomes a process of correctness checking that snowballs over time, making everything else easier and better (or else the tests need further adjustment!)
Right. You mean all behaviors are tested, essentially.
So if you / team are going to implement a new feature, what does that look like? Do you write Gherkin or similar, unit tests or both? Can you provide an example of what that might look like? How much of this has changed for you since the pre-AI days?
These days, yes, integration test at the high level (usually a 1-to-3 liner), then unit tests as I go, often some mocked functional tests. This is basically the same but a ton faster in the AI days, you have to hold the AI accountable and demand quality and iterate, but this weekend I've built an entire test suite for a monorepo I just started working on. It's garbage quality but better than no tests, of course, and will improve as I work.
There's also older work on github you can see over the years, a mishmash and grab bag, I would prefer if more of my work were open source but somehow most employers still default to closed source
Edit: While I'm thinking about it, the other thing you can do with AI is demand that it TDD things - I'm more of a "test all the fucking time" adherent, I don't care whether the tests are written first, but AI is perfectly happy to skate by making a tautological test unless you make it write the test first, ensure it fails correctly, make your change, and don't let it modify the test.
But what about navigating the code by the call stack? I didn't know that GitHub has a way to do that. Or maybe I'm probably coming across as being dumb enough to be talking about still trying to have a mental model of what calls what.
I've never used breakpoint debugging, was always a printf debugger. And now an agent can do that loop for me.
Prompt is usually something along the lines of:
>I would expect the behavior of this to be [X] - instead I'm observing [Y]
And the agent will form hypothesis, place printf statements, compile, and scrape logs on loop - each loop ruling out hypothesis or narrowing down what portion of the code is responsible for the unexpected behavior.
It has been able to pin-point the exact line(s) of code responsible every time I've reached for it so far.
For what it's worth, generally speaking I read all of the code and keep it in my brain - I have some uncommon assets in that regard like a high reading speed and great memory. `git grep` is the other tool I use often.
I rarely find that the call stack is the limiting factor, to me, and I suppose I do something similar to what you're talking about but just in my head - I know where a file is referenced via imports, what a function does, and what the flow of control is like.
> Do you not need to use the debugger sometimes? Or can cc debug by itself
A key feature of AI coding assistants and coding agents is troubleshooting. It turns out that LLMs excel at pattern matching, specially when coupled with feedback signals. It turns out that troubleshooting represents just that. A few years ago people searched the likes of stack overflow to fix problems, and it turns out LLMs can do the equivalent of that much faster.
But tests show you if a bug is happening, they don’t help you understand the underlying cause of the bug. In a decade, you haven’t hit a compiler codegen issue, a silicon erratum, a race condition, or anything that required actually spending effort understanding the causal path?
I don't know what to tell you besides that I've found more, better bugs using comprehensive testing than I ever found with a debugger.
The sole exception to that is that, back in the very early days, troubleshooting IE6 really required a debugger. But everything else, from memory leaks to thread hang issues to deadlocks, testing is better.
Where I am headed, I think, is to basically be a platform engineer. The job is to create the guardrails, validation, prompt library, and both agent and manual reviews; that keeps the domain experts safe when they start using coding agents.
It's a little bit like being T2/T3 customer support [or support engineer], but internal. You're there to catch the dangerous spots, the weird edge cases, and to make sure that everything is set up correctly, rather than to solve 100% of the routine problems yourself.
There's also plenty of room for cross-cutting-concerns, of course
Eventually infrastructure will be more simple to orchestrate too without faults I suspect from well developed devops harnesses. The risk and scale companies are willing to accept will still fall on humans for some time even then. I don't see most people vibe coding a million user app that has deeper needs than the basics we see now.
I honestly just go with whatever the company is using - these days often typescript, and I build tooling and systems that catch errors and review PRs produced partially or completely by the domain experts. Nothing fancy about it, just good old engineering, where when an issue arises you create a test for it and make sure it can never reoccur, educate users, set up the correct infra, and lock down permissions (it's never been easier or more fun to set up an incredibly draconian role in e.g. aws IAM)
I prefer that sample work be longer, substantially comprehensive and serious work as you say, but that the candidate's time be compensated on completion with either a direct honorarium in a fixed amount (something modest enough it's not worth applying as a job), or a larger donation to charity of their choice. That realigns the candidate and employer experience by showing that the employer cares enough about the output to invest in it.
Wow, that's a wild prescription, presumably ICL would be a huge quality of life difference for you! You could get within a diopter or two. I've been contemplating it at only -6, my commiseration on the multiple focal lengths.
Yeah, I've wanted ICL for years, but I could never afford it out of pocket, and all insurance considers vision correction aesthetic. Which is freaking stupid: There's a huge difference between me and someone who's a -2.
I might be able to stretch it now, but I'm coming up on my presbyopia years, so I'm not sure it's worth the money if I'm only going to get a few years of stability.
At this point, I'm hoping I take after my mother and get some really early cataracts because then I can just pay for the lens and the insertion/replacement will be covered.
If you can afford it, I would go for it, though. Personally, even for people who are candidates for PRK, LASIK, etc. I think ICL is still worth considering because it has some benefits. Less risk of dry eye and the ability to change the lens if your prescription changes. Longer recovery period, though.
I know I'm not a candidate for PRK/LASIK/LASEK due to dry eye (curse you programming!), so ICL was always my fallback, but like you I'm approaching the point where presbyopia is going to be a concern.
* https://en.wikipedia.org/wiki/The_purpose_of_a_system_is_wha...
reply