The reason you heard that was probably because they were talking about a more specific circumstance. For example SQLite is often used as a database during development in Django projects but not usually in production (there are exceptions of course!). So you may have read when setting up Django, or a similar thing, that the SQLite option wasn't meant for production because usually you'd use a database like Postgres for that. Absolutely doesn't mean that SQLite isn't used in production, it's just used for different things.
This sounds very "the perfect is the enemy of good". Tests don't need to be perfect, they don't need to be written by different people (!!!), they don't need to cover 100% of the code. As long as they're not flakey (tests which fail randomly really can he worse than nothing) it really helps in development and maintenence to have some tests. It's really nice when the (frequent) mistakes I make show up on my machine or on the CI server rather than in production, and my (very imperfect, not 100% "done properly") tests account for a lot of those catches.
Obviously pragmatism is always important and no advice applies to 100% of features/projects/people/companies. Sometimes the test is more trouble to write than it's worth and TDD never worked for me with the exception of specific types of work (good when writing parsers I find!).
From my experience though I often do make logical errors in my code but not in my tests and I do frequently catch errors because of this. I think thats a fairly normal experience with writing automated tests.
Would having someone else write the tests catch more logical errors? Very possibly, I haven't tried it but that sounds reasonable. It also does seem like that (and the other things it implies) would be a pretty extreme change in the speed of development. I can see it being worth it in some situations but honestly I don't see it as something practical for many types of projects.
What I don't understand is saying "well we can't do the really extremely hard version so let's not do the fairly easy version" which is how I took you original comment.
For something this simple that doesn't need to grow or interact with the rest of the system why would you need Backbone or React? And why would you expect any version to be shorter as it's mostly just the HTML and the data.
I remember writing Backbone applications with lots of deeply nested components. Trying to keep all the state in sync and reacting to events. It certainly wasn't simple and straightforward.
Enjoyment is not a binary thing. Some "enjoyment" is very low-level, and instantly forgettable. But it's easy and frequently we're lazy. Getting up and doing something else frequently ends up be more enjoyable.
360 degrees in a circle predates Plato by quite a lot (2000 years I think!). It comes from the Summarians more than 4000 years ago. They used a method of counting on fingers that goes up to 12 on one hand and 60 using both hands, so their numbering system was based on 60. 360 is 6 * 60 and also roughly how many days in a year.
Later societies inherited that from them along with 60 minutes in and hour.
So it monkey-patches a set of common http libraries and then detects calls to AI APIs? Not obvious which APIs it would detect or in what situations it would miss them. Seems kind of dangeorus to rely on something like that. You install it and it might be doing nothing, You only find out after somethings gone wrong.
If I was using something like this I think I'd rather have it wrap the AI API clients. Then it can throw an error if it doesn't recongise the client library I'm using. This way it'll just silently fail to monitor if what I'm using isn't in its supported list (whatever that is!)
I do think the idea is good though, just needs to be obvious how it will work when used and how/when it will fail.
Surely this now means now hiring managers (and people your code incorrectly identifies as hiring managers) now get spammed with loads of bullshit generated messages. Which obviously they'll ignore. But now you've made their jobs a bit harder by breaking a previously (maybe) working communication channel.
So you've put a effort in to build a product just to make the world slightly worse on net. Not hugely worse, but still it doesn't seem like the best way you could have spent your time.
Things are turning truly bonkers right now. I've hired two developers in the last couple of weeks:
1. One from my network, just announced it, someone I had worked with in the past reached out, quick chat, hired, great.
2. One with the usual approach of posting job ads and all that. We got an _insane_ amount of noise, even as an obscure, small company. I've hired hundreds of people, but most of those three years ago or earlier. Never seen such noise, most candidates barely meeting any of the requirements, weird auto generated cover letters and CVs. It was a bit exhausting, but I went through everyone manually to make sure I'm not accidentally filtering out a solid candidate. We found two in the end, one quickly backed out because they got another offer. But there was one good candidate left, and they accepted the offer. I don't remember this being so hard.
A few years ago I'd call people trying to automate screening or mainly hiring from their network lazy. In this time, I see the appeal.
The last thing I need is more bots spamming me on my LinkedIn account on top of all this madness.
I think some recruiters are already doing AI-slop, too. (Not just the LinkedIn-spamming templates that some sourcers were doing before.)
Hopefully we'll get a big backlash against disingenuous passing off AI-slop as a communication from a human.
Maybe sending someone an AI-slop message will become universally recognized as trashy behavior -- employed only by the corporate communications of companies that really don't care, but not by anyone respectable.
The reaching out might work, I know some people actually appreciate it. I personally don't, it feels like an attempt to circumvent the system, and the system is in place for a reason: It attempts to make the insane volume of candidate messages manageable. It's not perfect, I wish more people would work on better systems rather than ways to circumvent them.
There is one notable exception to this, a guy I actually ended up hiring: The job ad link I posted stopped working after a few days, and he wrote a nice message to the company (!) email address telling us about that, and saying he's interested if the role is still open. That's proactiveness I really appreciate. It's very different from random people reaching out on my personal LinkedIn account or email, which I simply ignore.
I'd _love_ it if there wasn't so much noise, then I would probably think about it differently. But the volume does burn you out, and any attempts at circumventing systems put in place to try and manage this is not helpful.
And that's for manually written messages. Automating that - Jesus.
you should always pre-vet any message you send and sign with your name.
it doesnt really matter where the message or how was created, only that you're 100% ok with its contents reaching its destinatatary.
that still puts some limits to how much you can -spam- and should make you not want to -spam- but only send real messages, but you can certainly use AI to help you research/generate those leads initial messages
i have not tried to do this, but i wouldn't see how its problematic?
That’s how I would use this (and is my approach to LLMs in general). I’m just afraid that others would take a more lazy approach and spoil it for everybody else: https://news.ycombinator.com/item?id=44274583
Yeah, but (if I understand how your product works correctly!) I’m afraid the laziest of your users would just copy-paste the suggested message and send it as is, to as many people as possible.
This would quickly saturate the decision-makers’ inboxes, and even those who genuinely put some thought into the roles they apply to and rewrite the suggested openers would be lost in this cacophony.
quick question: have YOU tried actually applying to any jobs right now? go on Linkedin and you'll see every JD has like 100 applications. Is this what you call "working" process?
It's not. But I think you might be able to use your energy in ways that don't make the noise problem _worse_. Sure, if you don't do it, somebody else might, that occured to me. So what can one do?
1. Perhaps pivot to building a tool that cross references companies hiring with people attending local user groups or conferences you're interested in, to show an overlap? That might give you a hint about what circles you could enter for networking. Manual, human networking. It'd still be work, but a place to start. Of course this is stuff that's better to start when you're still employed and interested in a change, not when you've been applying for months. But it's one idea.
2. Try to work the other side. Why do fitting candidates get filtered out? Can you build a better system than what companies are using already? I wrote another comment about just how hard hiring is with all this automated spam, I'd love a human solution. This is hard of course, but I think I won't be alone and many companies will have similar experiences. Might be a problem they want to pay money for, but it's arguably harder to get than from job seekers.
Just some ideas. I emphasise with the situation and it's cool that you're trying to do _something_. Don't let folks like me discourage you from solving the problem. But consider the feedback on your proposed solution and consider other options to solve it, perhaps.
I haven't, but it sounds honestly really bad. Sounds like it sucks for everyone right now. I just think your product will make it worse, probably only very slightly worse but still worse.
