> To make things even worse, the community that has most thoroughly embraced them are compiler authors, who many programmers think of as being an impossibly skilled elite
The article's approach seems super ad-hoc, leaving you to have to think hard, do all the work, and make all the mistakes.
If you were to go down the other path, you might try dividing and conquering the problem. An arbitrary Pair<A,B> is trivially constructed from an arbitrary A and an arbitrary B. So if you can generate a string, and a number, you could generate a User full of number and string fields. If your generate function accepts a number describing how complex a string to make, then you can also choose how complicated to make your User. That's all shrinking needs to be. Repeatedly trying smaller Ns while the problem still happens (the problem being one of your unit tests - not an additional "interestingness" test you need to write.)
You'll probably way more likely to hit boundary cases by using the structure of the input and making interesting variations that way, rather than hoping you can permute the right bytes from the CLI.
For more than 20 years I've been doing automatic test input reduction as part of testing Common Lisp compilers. The reduction is on randomly generated inputs, but they are structured in such a way that reduction always gives a valid program that should (in the absence of compiler errors) not signal an error.
It's a tremendously economical way to test compilers. For a modest and finite investment in testing infrastructure I get an unlimited number of tests. Over the years I've run many billions of test inputs on various Common Lisp implementations, although I'm mostly focusing on sbcl these days. When a bug is found the input quickly reduces to a something small that usually immediately tells the developers where the problem is (usually but not always something introduced recently.)
I also have a testing harness that cobbles together usually erroneous Lisp code and sees if the compiler blows up (the sbcl compiler as designed must never throw an error condition even on erroneous input.) This exploits a corpus of public Common Lisp code, combining and mutating the code in various ways.
When asked whether it will be possible to fix Sora's videos after they've been generated, Murati said "eventually," and then couched that by saying "that's what we're trying to figure out...how to use this technology as a tool that people can edit and create with." She promised that there would "eventually" be "more steerability, control and accuracy...and reflecting of intent of what you want."
You'll "eventually" be able to add audio to Sora videos, and when asked when Sora's generative videos will be available to the public, she once again said "eventually," and when pushed said that Sora's launch would "definitely be this year, but could be a few months."
Murati, living in a world of "eventuallies," provided no technical insights, no specifics, and very few details.
The usual flow is that I have a great HR interview, then I'm assigned an online intelligence (what dots should be in the next box) test and a personality test, and then the company wants nothing to do with me.
They manage to screen me out before I have the opportunity to talk about anything computing related.
(The old horror-stories of 'I couldn't reverse a BST on a whiteboard so I didn't get the job' seem wonderful in comparison now. The non-computing people have captured the hiring pipeline into computing companies)
There are dozens - dozens! - of us outside the US.
I drew the opposite conclusion from your link: (Title VII of the Civil Rights Act prohibits employment tests that are not a 'reasonable measure of job performance'). All an employer would need to say is "We've found that people who can't dots-in-box are bad at cody"
Coinbase wanted me to do one before I did the second round of interviews and I'm in the US. Intelligence and personality tests. Wound up telling them that I didn't want to enable the type of discrimination they facilitate and that with the best faith reasoning for using them is at best a sign the company is indexing on the wrong things for hiring.
Anecdotally, I've only seen them done in northern European companies, but every northern European company I've interviewed for had them. It seems to be a regional-ish thing.
Not if they are dressed up in a particular way, and not if intelligence is genuinely relevant. I have done a few of these tests for jobs in the US before. They are just bad.
The 2000 census gave enumerator applicants a small multiple choice test that was similar to an IQ and then they hired foremen and line workers working down from the highest scores. I've never worked with as many smart people at a temp job!
NAL, but have worked in this. Griggs is a bit more complicated than that, and its progeny modify application anyway.
The TLDR is that arbitrary tests are permissible if there's no disparate impact. Tests with disparate impact are permissible iff they are not arbitrary (i.e., "directly" assess job responsibilities).
So, for example, Leetcode may have disparate impact, but it's "direct" enough to be permissible. On the other hand, most "AI Assessments" are actually so badly implemented that they're effectively random - and a coin flip won't have disparate impact.
IIRC the personality tests are mostly designed to assess how a candidate deals with authority and to try and suss out if they’re consistent/honest. Testing for ‘personality disorders’ more or less.
I doubt the tests actually help, due to the reasons you provided (and more).
A lot of corporate "metrics" are pseudoscientific. They have a superficial veneer of being "scientific", because there's, like, math and numbers and stuff, man. The world continues to function despite this foolishness, not because of it.
Part of why this is so popular in the US is because the US is a hyper-individualistic culture. In other countries, relations are more important. This irks Americans who think this necessarily entails nepotism (it can), but I would say that 1) this overestimates the relative effectiveness and objectivity of low-info hiring practices, and 2) ignores the fact that all knowledge of another person occurs only through relationships. We're inherently social animals and organizations are inherently social phenomena. (2) is partly why many companies pay referral bonuses. They're relying on the knowledge of someone you have of someone you know. This makes sense. If I've worked with someone, I am in a much better position to evaluate their qualifications in a meaningful way than some HR person or some random whoever. A sane company doesn't care about satisfying some weird, arbitrary ideological benchmark. They care about assembling a team that can work effectively.
There's a mindset that freaks out over the mere potential for something to be abused or suboptimal or whatever, and categorically decides that it's better not to have that thing at all. (Gov't is a great example. Yes, gov'ts can become abusive, but they're also the only force that can stand between you and, say, abusive corporate power.)
I passed a series of those and since I remembered the questions from a relatives autism diagnosis testing I asked what they do since they are effectively filtering for things like that.
HR rep said those applicants should probably go see a shrink instead (!!???) and that was the end of me interviewing there.
The testing needs to end. The people using these tools don't know how they work, what they are testing and what blanket denials of personality types really means.
About 20 years ago, I remember getting my hands on an answer key for the personality screener used to work at Target. This was just for a $7/hr cashier position, but it had a very low pass rate. To them, the ideal candidate for them was: always positive and optimistic, preferred being around people than being alone, never complained, frequently sought approval from peers and authorities, always followed every rule no matter what.
So it wasn't explicitly designed against people with disabilities, the rule-following aspect may be more present in autistic people - but for a lot of these, I can't see many people passing if they answered honestly.
"I know the rules of the game and what it will take to continue to be employed in this position."
---
One employer I had gave a test that included such questions as "It is ok to get into fights behind the store if you are not on the clock" and "It is ok to take inventory as long as it costs less than $5."
You don't see how a customer facing position in a retail chain would reasonably want all these personality traits in their hires as a matter of operating a good business?
Wanting those traits and asking about those traits in a self-reporting questionnaire are two different things.
If it’s a questionnaire you are functionally just screening for liars or people who don’t know how to use the full spectrum of a distribution and put in 5/5 or 0/5 for everything.
I am miserably bad at soft-skills interviews and never get past this round. Been over a year since I've had somebody actually try to assess my technical competency in any real capacity.
I'm also getting maybe 1 INITIAL interview every 3 months right now because of this AI screening stuff and I just haven't felt like re-writing my resume to game them.
IMO, soft-skills interviews more a test of your storytelling abilities than anything else. At Google, people often used to joke about candidates who cannot even pass the Googleyness interview, which is supposed to be the easiest of all Google interviews.
One thing I discovered years ago was that even if you are pretty good at soft-skills type stuff and also pretty good at technical stuff what I couldn't do is context switch between an hour or so of doing "soft" stuff to a technical question - even though it was a trivial question. I lost a CTO position over that - mind you I think they went out of business a couple of years later...
If you're trying to cultivate a chill workplace with colleagues you enjoy having coffee with, that's a different objective from building software which works correctly.
Right now I'm trying to watch Book of Boba Fett on Disney Plus. When I cast Disney to my TV and hit play, it shows the animated Disney logo and sound for about a second, pauses/buffers for a couple of seconds, and then skips to the start of the next episode (and so on, until it runs out of episodes). I can temporarily fix it by turning everything off and on again, and starting the episode on my tablet before hitting the cast button.
Lots of people have a hard time just freebasing in an abstract conversation about how they work and storytelling “My Journey” type stuff but work just fine in an actual team setting with concrete products, features, and problems to think and talk about.
This is the stuff with which I struggle the most. I'm an introvert, and "my journey" sounds so insufferable and egotistical to me, I physically cringe at the thought of having to talk about this kind of stuff.
At the end of the day, I just want a paycheck and to work on at least marginally interesting problems. I'm not interested in having to lie about how passionate I am about what company X is doing, nor am I a salesperson that feels comfortable hyping myself up. It feels so fake it becomes a distraction during the interview, which causes me to freeze up and start floundering.
I work hard and I take pride in what I produce, I have plenty of hobbies and get along with others well, and I thrive in environments where I get to mentor and be mentored by others. These are the soft skills that are actually important for working on a team, but they're the most difficult to convey in the traditional interview format.
The guy from the carbon fiber + silver tape titanic sub had super people skills. But if you don’t want to be crushed in a submarine by a 10.000 feet water column, you’ll rather have the clumsy/awkward/jerk guy with superb tech skills leading the project.
I suspect the counfounding factor of hundreds of other applicants makes it hard to tell whether you're specifically being discriminated against or just one of the 999 people who didn't get the job.
(There are some extreme measures that you can try like applying under a different name, although that then forces some awkwardness later on when you actually need your government name for tax and bank information)
> The old horror-stories of 'I couldn't reverse a BST on a whiteboard so I didn't get the job' seem wonderful in comparison now
> They manage to screen me out before I have the opportunity to talk about anything computing related
When I was in college about 10 years ago, I was dreaming a company would interview me on actual algorithms, but sadly I rarely had the occasion to do anything above basic coding.
If you want to see clearly what you can do to get hired, the following perspective helped me a lot. From experience, most hiring processes seem to be shaped less by technical signal and more by the interviewer's defensibility strategy in case of a bad hire. What I mean by that should be clearer from the list below:
- informal interview plus experience matching, hires based on how similar candidate prior jobs seem to be for current role <- if candidate is bad, the interviewer can justify the decision by pointing to the candidate's background.
- informal interview and vibe check with the team or personality test check if candidate is compliant if senior or charismatic if junior <- if the hire is bad, responsibility is diffused across the group.
- take-home project with a nominal 1-hour time limit, but an implicit expectation that candidates spend days on it. Since the interviewer cannot verify how long anyone spent, they default to rewarding the most polished submission.
- take-home project with narrow stated requirements, followed by judgment against unstated "best practices" the company follows <- if the hire is bad, the interviewer can point to the candidate's code and show it matched already what the company looked for, since the style is recognisable.
- CV farm, the company is collecting CVs and has no serious intent to hire <- interviewer doesn't exist
- if the interviewer has no skin in the game (is not verified, performance doesn't matter, they're a consultant leaving next month anyway), anything could happen. This is the most dangerous kind of interview because almost anything can happen and it gives you the least actionable data.
- formal interview pipeline, usually found at large corporations or in finance; interviewer has a clearly scoped job and are expected to evaluate one part of the candidate against a rubric, not make a general judgment about overall hireability. Biases will still exist, but they are more constrained because the process uses multiple interviewers, trained evaluators, explicit scoring grids <- if the hire is bad, the decision is defensible because the interviewer followed the assigned process.
So, interview pipelines can be predictable. It is that you should identify what kind of process you are in as early as possible. If it is experience matching, make your background look obviously adjacent to the role. If it is a take-home, assume polish will count more than the stated time limit. If it is a vibe screen, technical skill may not be the primary variable. If it is a formal pipeline, prepare for the rubric. And if it is a CV farm or a low-accountability interview, do not over-update on the rejection.
In your specific case, I wouldn't overindex on on the intelligence or personality assignment. More probable the CV already got deproritised, but they also sent you the test automatically. The rejection may tell you less about your ability than about the kind of pipeline you were in.
> hires based on how similar candidate prior jobs seem to be for current role <- if candidate is bad, the interviewer can justify the decision by pointing to the candidate's background.
I have found that people are often not very good at doing new things, so it is much easier to find someone to do the same job they've already done than to ask people to do even a slightly different job.
Some people are adaptable, but the vast majority are not.
They are smart enough not to say. The usual pipeline is HR then both Alva tests at once (which seems backward to me - why not use the screen as the actual screen, instead of wasting an hour of HR time). All I know is I'm in their pipeline after the HR but not after the Alva tests.
Let me rephrase that. In your own view, with which component of the test do you think you're having trouble getting through? How many times has this happened, and if it's more than twice have you considered some of the various test practice resources?
It's not the database, it's the lines of code making calls to the database.
If you're invoking your DB via C code, you will not get help with memory-safety. If you're invoking via non-Haskell code, you won't get help with transaction safety.
The "transaction safety" part is confusing. What they mean is if you use SERIALIZABLE, transactions need to be retried, so your code inside the xact should be idempotent. I guess this is safer in Haskell because there are no variables, but that doesn't stop your code from having other side effects.
If you're using the product, and you want to question or debug what's going on, you can:
* Jump directly to the single relevant part of the frontend responsible
* Likewise with the backend. The layout and naming of the code should scream its purpose.
* Once you're looking at the code, it should be trivial to run it, right now, instantly, in unit test, or cli. You shouldn't need to stand up a database to see whether your code rounds taxes the expected way.
The system contains its own checkability. You can, for instance, just sum up all the incoming money and outgoing money and see if your balance is correct. (It's not enough to have good tests today, if you're working on data that was incorrectly calculated and stored yesterday)
'Keeping up with regulations' may as well be a separate field from the core stuff. It has the same pressures as any other development effort. Managers will want the integration to the KYC service LLM'd as quickly as possible.
> fork() is a relatively expensive system call; it must copy the entire process state (including memory) for the child process. Many optimizations have been made over the years, but a fork is still a fundamentally costly operation. To make things worse, a fork() call is often immediately followed by an exec(), which will discard all of that memory that was so carefully copied for the child.
It's weird to leave out a mention of copy-on-write - the optimisation that means that you don't copy over all the memory.
This was left implicit in the article, but what they mean by copying the process state here is the memory management structures. That's mainly the page tables and the VMAs.
That means you have to allocate new pages to hold a copy of all these structures, even if the actual memory pointed by the pages is shared. And walking all those structures to make a copy is still costly.
Redis is the kind of process where this matters a lot, and while fork() doesn't copy the memory, it still needs to copy the page table. For a process holding tens of GBs of RAM, fork() can take a long time, and there's one every time Redis dumps its .rdb file or rewrites its binary log ("AOF").
On an m2.xlarge using ~25GB of RAM, fork() took 5.67 seconds. That's a long pause when Redis clients typically experience single-digit msec latency for most operations. Yes, that's only the time needed to copy the page table. It's surprising they don't mention huge pages, it seems like it would be a key consideration here.
No doubt hardware is faster 14 years later, but Redis instances likely use more RAM too. It'd be interesting to see this benchmark revisited.
It says state. Copy on write still means it's O(number of page table entries) even if you don't copy the contents. It's a well known issue that forking a program with large virtual memory size is slow.
Even with copy-on-write, fork() still has to pay the setup cost for COW. If the parent process has a lot of busy threads (e.g. Java), you can end up doing a lot of unnecessary COW before exec() fires.
vfork() does NOT stop the world in many / most implementations. The ones that do stop the world do it because someone misunderstood the whole "vfork() stops the parent process" -- yes, it stops the parent process in a pre-threads world, but it doesn't have to stop any other threads but the one that called vfork(). Indeed, many implementations don't do that.
(Someone once tried to make NetBSD's vfork() stop the world because that's what the pre-threading man page said it does. I did my utter best to keep that from happening at the time, and it didn't then. Hopefully no one tried again later.)
I’ll re-read it, because clearly I don’t get it. And I’d like to.
My first two attempts made it seem like it was building on a function calling itself, with itself as an argument (so that it can call itself). I’m not sure how that isn’t recursion, and I didn’t read it as throwing away those approaches. But, as I say, I’ll re-read it…
author here. the idea is to see how the Y and Z combinators come out relatively naturally given an extremely constrained context with no loops, no recursion, no bindings. the article is intentionally structured as a sequence of failed attempts that progressively reveal which phenomenon is still responsible for the recursive behaviour.
in the article, i define recursion narrowly as "... call the function `fact` from inside the definition of the function `fact`".
you're right that `factgen` is also not recursive but it is also rejected, but for a different reason: self-reference. declarations are banned precisely because they give a function a "name" that can be referenced later.
please note that the solution which uses Z combinator (given at the end) grows from `(x => x(x))(x => x(x))`, which is NOT self-referential. it achieves self-replication by literally rewriting the content of the function twice, which is different from self-referential recursion of `factgen`.
I think I missed the significance of your narrowed definition of recursion, and didn't apply it the way you intended when I read the article. I admit to my bad reading.
I went on to discuss your article with an LLM and used the experiences I've had _using_ some functional approaches in JS to help it give me a tutorial on the combinators, to try to better understand your article and the underlying principles. I "mostly get it" now, but I will have to go over it a couple more times.
You shared a thought-provoking article, even if I didn't immediately get your intended lesson out of it.
I don't really see this as analogous. Yes, you do choose an abstraction level to operate at, I rarely think in terms of transistors, or even gates (which by your logic an assembly programmer should do).
But I often do think across adjacent abstraction levels, because abstractions are (varying levels of) leaky. Modern compilers are after many decades good enough and modern computers fast enough that it is rare that I need to dig into the assembly (but I happens, compiler explorer is in my bookmark bar in Firefox).
Other abstractions are far leakier, it is far more common that I look in wireshark to debug network issues, the application level view is often not enough.
One of the leakiest abstractions currently is LLMs. Maybe in a decade or three they will be good enough, but they aren't yet, that's for sure. At least for the hard realtime systems level programming I do. For code generation they often make enough mistakes that the time spent after review and fixes comes out in the wash, even for simple tools. Their use for bug finding, RAG and similar is however promising.
My lived experience over the past few months is proving you wrong. I started with your position and have since been able to see how good the tools are when properly used. I've also noticed a huge gap in ability among engineers and I think the gap is widening. My theory is that some folks have the premium tools and some don't and the ones that don't are sort of in this weird limbo where they are sort of stubbornly annoyed at the idea of having to pay for these things so they lash out. Understandable but ultimately self defeating. You can in-fact force the LLM to use any pattern you want. I encountered this recently with a hand made framework I wanted to upgrade. It did stuff I didn't like. But well guess what? I provided it new constraints and it started to do what I want. Be as opinionated as you want. That's the whole point. It's basically your intern.
> My theory is that some folks have the premium tools and some don't and the ones that don't are sort of in this weird limbo where they are sort of stubbornly annoyed at the idea of having to pay for these things so they lash out.
At my last job the employer paid for OpenAI access for all of us.
Baby sitting an LLM is not my idea of meaningful use of time. And reviewing code that someone else had an LLM spew out even less so.
I am not lashing out because I don’t have access to LLMs. I had access and I did try it plenty.
This is really low effort man. You can do better than "You're not paying enough to be as good as me" followed by "oh...well you haven't paid this month."
When I encounter people who don't use these tools it feels more like talking to someone without a computer who is trying to convince you that you don't need one back in the 90s. Or someone being like "the internet is useless" back in 1995. I mean early days it was kinda like that. The early internet for normies was almost entirely useless.
The change has been so rapid that I think a lot of people are having a hard time I guess wrapping their head about the lived experience of it. For a while my only access to the tools was through work. Then I ended up getting a $20/month ChatGPT account and that comes with codex and now I can't imagine sitting there Googling a problem anymore. It literally feels low tech these days. Big "I'm not paying for Cable, the antenna is good enough" energy. It saves me soooooo much time just maintaining my own local stuff. I mean it literally saves me hours and hours of personal labor.
The local models will 100% catch up. Most likely the inference I use now will be free in five years across the board and you'll be buying a cyberdeck or something with a 128G of RAM and an LLM friendly bus architecture.
> When I encounter people who don't use these tools
But you didn't encounter those people. People said they've used the tools, and then you said it wasn't recent enough. Not because you know when they've used it last, but because their experience didn't match yours.
It's great that it's working for you, really. But since you have been posting on HN a lot about this, while simultaneously claiming you don't care what other people do, maybe consider a different approach than calling everyone luddites. If people call you a shill, and you exit the conversation claiming you don't care, but then you go to the next thread doing the same low effort stuff, don't be surprised when people see a pattern. There are lots of people communicating more effectively about this.
Don't confuse the cost of org wide LLM services with coding. Two different things. Most people at any org probably just want ChatGPT so they can write reports and do research. And now they want it to sync with Google Drive or w/e so they can pull in docs. Obviously that stuff is classic B2B Software as Service hosting. Prices will go up just because that's how B2B prices work when enterprises negotiate yearly services but overall it's not the most expensive line item by a long shot and power users are only a small sub set of the population of all the users.
But for code it's a race to the bottom because it's all text and local works quite well. You can host models on LangSmith and similar and because people use those services to create chat bots the overall use of them for coding is a very tiny fraction of their overall usage. The race to the bottom is further exacerbated by the fact that as GPUs become more powerful you can host more per unit so the cost of text inference will drop precipitately. Right now people are reporting that for some of the self hosted services they are able to do everything for under $5 / month. That price WILL drop because that's how computers work.
> I'm sure they were blindly accepting the Assembly coming out of the compiler.
The fact that you consider deterministic output from a compiler the same as probabilistic output from a LLM makes me think you don't know how either of those things work, even at a very superficial level.
Compilers are orders of magnitude more reliable than LLMs. There's a reason the saying is "it's not a compiler error".
I have a standing challenge to my co-workers that valid compiler errors will be rewarded like a birthday party, with the baked goods, alcohol, or sweets of their choice. It's only been redeemed once, and I've found less than a dozen unreported compiler bugs myself.
Where do you think those bugs reports for gcc and others come from? Some people do look at the assembly coming out of the compilers.
Currently the openbsd mailing list for port is currently going through a clang update and one of the main point is looking at all the packages that failed to build. I even took a long look at the usb stack and the audio subsystem of OpenBSD because of an issue I was having with my DAC.
I literally do packaging for a living and you are misunderstanding my point. Most people just take a binary and run it. There's no analysis of the assembly code. You might profile it and bench it after the fact but no one is sitting there looking at the assembly line by line unless there's a very very good reason and frankly LLMs are better at that type of investigative work. I know because I've been investigating some curious 1 in 100,000 segfaults recently and guess what? It took an LLM to build a tool to let us even hit that bug because it was basically impossible to do by hand and no one in the before times would have sat down to write the tool cause we would not have time so we would have just accepted that 1 in 100,000 requests are segfaulting. At least now I can actually fix the problem.
What's the reliability of compilers this day? How likely for a bug to be in your code and not in the compiler? I think it's close to 99.99...
So when you have a bug and a core dump, you can quickly load it in debugger, see the stack frame and then theorize a model for the bug to happen. If after verifying the source and having complete confidence that it's good, then you start looking at the assembly, most likely while single stepping with the debugger. But you rarely get to that point, because 99.99... it's your code.
That reliability is what AI tooling is lacking. It's exhausting monitoring the output because errors can be as simple as a minus character or the wrong comparison operator.
I'm usually compiling other people's code. Hitting that 1 in 100,000 issue in run time and then having to come up with patch. And then have to make sure it's okay in arm and amd64. The bug I'm thinking of is decidedly a human output and the LLM is cleaning up the slop.
Once you reach a certain skill level you really didn’t ever visit SO anymore. I basically just live in Postgres, Redis, Ruby and Rails documentation. Still do.
I don't think I was ever able to straight copy and paste from SO, everything needs adaptation, and code can often be simplified. And you need to understand your code. SO was useful, but nothing could be used copy pasted.
Maybe this is not the case if you are doing a dozen throwaway websites, but for anything serious that is an absolute requirement. I work in hard realtime safety critical code, think things like brake controllers, medical devices, auto pilots, etc. In my case industrial control systems. You need to have full control and documentation for your development process.
I agree with the notion it's an age thing, but not because I am old, but because the tools are different. When I was learning to program as a kid I blindly 'copied and pasted' from computer magazine. I typed everything in, not understanding what I was doing, and made mistakes. Then came the tedious problem of figuring why the code didn't work. What was the syntax error? Why was it wrong? Why did the computer crash when I poked the wrong memory address?
I learned to debug and built comprehension by typing it in, and built it as a practice. Later in life and career I learned the value of transcription rather than copying and pasting because it at the very least forced me to read and write what I was copying, and built the base and familiarity I needed to learn from what I was copying.
That extends to how I use AI today. I use AI tooling to explore the concept of what I am building, use spec based designs to build solid outlines, and scope individual coding sessions, so that even when I use AI to build it, I have read, edited, and managed the design, and when I run into parts that I don't consider boilerplate I treat it the same way, transcribe what was attempted to understand why it was failing, and make sure I understand what the AI is doing that I haven't done before.
Most code we write is boiler plate nonsense. Writing out React components manually doesn't make me better at writing C. Like it literally is a waste of my time. I could be focusing on "real problems" like the way light diffuses in my simulated atmosphere in my 3D engine. But no I gotta sit there and manually wire up the onclick event for some button or whatever because it doesn't pass the HN sniff test from some pedantic random. Yea trying to fix one of my old job's webpack build for 3 weeks sure did build character. My boss hated how long it took. I hated how long it took. And thank fuck I NEVER have to do it again.
The amount of times that copy pasted code will work verbatim is basically 0. Better to type it out manually so you can tweak it as needed and you understand it better.
> SO was just an example. If you try to tell me you've never copied/pasted code before I know you are lying.
I've never done that; many experienced devs I know have never done that. We barely used it, in fact! The few times I asked a question, the answer was not "Here's a piece of code".
Look, this comment of yours, coupled with a previous comment from you in this thread (demonstrating you don't know the difference between probabilistic and deterministic output) makes it painfully clear you don't do development; or at least you didn't until you were handed a magic "write me a program" tool...
> Where does this idea come from that good programmers were ever cool with that?
r/programminghumor mostly. It was always tongue in cheek, but people took it too seriously.
However, the number of times I’ve gone over to help a colleague and realized they were trying to copy/paste code from SO, without even reading the context of the thread is baffling. Like, why did you expect it to work in the first place? I really try to be humble and not make assumptions about people competencies but it’s really hard to have those experiences and not think the average programmer is just an idiot. It’s no wonder AI is helping people when this was the baseline.
Some things are easier to verify than they are to solve, right?
So if you see an answer on stack overflow, read it, comprehend it, and you can pretty easily mentally verify the correctness to a sufficient degree of confidence…
> Where does this idea come from that good programmers were ever cool with that?
Copium from folk who were never developers before, but who now want the badge anyway. Too bad the same badge can be given out to a bright 12 year old who doesn't know the difference between a variable and a type.
I suppose I'd have to admit to not being a "developer" anymore, because developers in the age of AI won't know how to write code. Perhaps I can still hold on to the label "programmer" for a little while longer.
> With that Github and personal portfolio I wouldn't be making such sweeping statements.
Where's yours?
After all, my CV (online like everything else) shows almost 30 years in the field, 7 of which as a research scientist, 6 of which was spent writing software for munitions, many of which were spent as an EMV developer, a stint at a FAANG...
All you've done is state the things that very junior devs state, with just as much confidence.
I started coding before Stack Overflow existed, and those were the days when coding was most fun for me. Learning HyperCard Basic from the manual that came with the computer was so full of joyful moments.
Stack Overflow had it's heyday, but by the time AI came around I already wasn't using it. Stack Overflow for a long time has been inundated with the kind of people who think everything is the XY problem[1], and arrogantly assume they know what your problem is better than you do. Stack Overflow was all-but-useless for at least 5 years before AI broke into the public eye.
I don't think those two things are comparable, really.
With SO copy/paste, you still were undertaking the mental exercise (and reward) of thinking through hard problems, researching solutions, and assembling it yourself.
With AI, you literally outsource most or all of that. The way some people "vibe code", they barely are engaged with any of that process, if at all.
I think about it like I do video games: it's a lot of fun to play them, and while it can be interesting to watch someone else play, it's just not the same.
The article's approach seems super ad-hoc, leaving you to have to think hard, do all the work, and make all the mistakes.
If you were to go down the other path, you might try dividing and conquering the problem. An arbitrary Pair<A,B> is trivially constructed from an arbitrary A and an arbitrary B. So if you can generate a string, and a number, you could generate a User full of number and string fields. If your generate function accepts a number describing how complex a string to make, then you can also choose how complicated to make your User. That's all shrinking needs to be. Repeatedly trying smaller Ns while the problem still happens (the problem being one of your unit tests - not an additional "interestingness" test you need to write.)
You'll probably way more likely to hit boundary cases by using the structure of the input and making interesting variations that way, rather than hoping you can permute the right bytes from the CLI.
reply