Sometimes. I have often had to say "no" because the customer request is genuinely impossible. Then comes the fun bit of explaining why the thing they want simply cannot exist, because often they'll try "But what if you just ... ?" – "No! It doesn't work that way, and here's why..."

I had to explain recently that `a * x !== b * x when a !== b`*... it is infuriating hearing "but the result is the same in this other competitor" coupled with the "maybe the problem here is you're not knowledgeable enough to understand".

We've definitely had our fair share of "IDK what to tell you, those guys are mathing wrong".

TBF, though, most customers are pretty tolerant of explainable differences in computed values. There's a bunch of "meh, close enough" in finance. We usually only run into the problem when someone (IMO) is looking for a reason not to buy our software. "It's not a perfect match, no way we can use this" sort of thing.

At this particular job I used the plus, the star (multiplication) and once I even got to use the minus.

There's a legend going around that a friend of mine has used division, but he has a PhD.

What you have to do is dig into the REASONS they want X or Y or Z (all of which are either expensive, impossible, or both) - then show them a way to get to their destination or close to it.

In the business user’s mind, negotiation means the developer can do X but the developer is lazy. Usually, it is requirement X doesn’t make any sense because a meeting was held where the business decided to pivot to a new direction and decided the new technical solution. The product owner simply gives out the new requirement without the context. If an architect or senior developer was involved in the meeting, they would have told the business you just trashed six months of development and we will now start over.

But fundamentally it just means "the base of data", the same way "a codebase" doesn't just mean a Git repository. "Downloading the database" just means there's a way to download all the data, and CSV is a reasonable export format. Don't get confused into thinking it means a way to download the Postgres data folder.

In today's world with all the SPAs that don't push to history or don't manage to open the correct page based on history, this seems like a valid requirement

It's up to you to work with them to identify key features and figure out precisely what to do.

For example in chess AI is already far better than humans. Including on tasks like evaluating positions.

Admittedly, I use "AI" in a broad sense here, despite the article being mostly focused on LLMs.

It's just never been that hard to solve technical problems with code except for an infinitesimal percentage of bleeding edge cases.

"People problems" are problems mainly caused by lack of design consistency, bad communication, unclear vision, micromanagement.

A "people solution" would be to, instead of throwing crumbs to the developers, actually have a shared vision that allows the developers/designers/everyone to plan ahead, produce features without fear (causing over-engineering) or lack of care (causing under-engineering).

Even if there is no plan other than "go to market ASAP", everyone should be aware of it and everyone should be aware of the consequences of swerving the car 180 degrees at 100km/h.

Feedback both ways is important, because if you only have top-down communication, the only feedback will be customer complaints and developers getting burned out.

100% management-induced problems.

I think AI will get there when it comes to “you asked for a gif but they don’t support transparency”, but I am 100% sure people will continue to write “make the logo a square where every point is equidistant from the center” requirments.

EDIT: yes jpg, not gif, naughty typo + autocorrect

Depends on what “transparent” means.

Why wouldn't the AI deal with that the same way human developers do? Follow up with questions, or iterate requirements?

The thing is, with enough magical thinking, of course they could do anything. So that let's unscrupulous salesmen sell you something that is not actually possible. They let you do the extrapolation, or they do it for you, promising something that doesn't exist, and may never exist.

How many years has Musk been promising "full self driving", and how many times recently have we seen his cars driving off the road and crashing into a tree because it saw a shadow, or driving into a Wile E Coyote style fake painted tunnel?

While there is some value in evaluating what might come in the future when evaluating, for example, whether to invest in an AI company, you need to temper a lot of the hype around AI by doing most of your evaluation based on what the tools are currently capable of, not some hypothetical future that is quite far from where they are.

One of the things that's tricky is that we have had a significant increase in the capability of these tools in the past few years; modern LLMs are capable of something far better than two or three years ago. It's easy to think "well, what if that exponential curve continues? Anything could be possible."

But in most real life systems, you don't have an unlimited exponential growth, you have something closer to a logistic curve. Exponential at first, but it eventually slows down and approaches a maximum asymptotically.

Exactly where we are on that logistic curve is hard to say. If we still have several more years of exponential growth in capability, then sure, maybe anything is possible. But more likely, we've already hit that inflection point, and continued growth will go slower and slower as we approach the limits of this LLM based approach to AI.

And what is the endgame for AI?

Also technologies don't develop like evolution really so not sure why you drew that comparison.

Technologies plateau for a combination of reasons - too expensive to make it better, no interest in making it better, can't figure out any more science (key people involved leave / die / lose interest, or it's just too difficult with our current knowledge), theoretical limits (like we are reaching in silicon chips). I don't see a lot of similarity with evolution there.

There's also no "ruling out" the Earth will get zapped by a gamma-ray burst tomorrow, either. You seem to be talking about something that, if done properly, would require AGI.

You can do anything with AI. Anything at all. The only limit is yourself.

Nobody can predict how soon a technology will plateau. People make predictions based on insane hot takes like "I pray to our new overloards who will make me immortal" and "there's nothing new under the sun, everything is just marketing"...

There might be the next AI winter starting starting next year, AI might wipe out humanity in our lifetime, even both of those might happen. Both very unlikely (qualitatively) ends of a huge spectrum.

That's not to say that we "don't know anything and thus give up talking about it". Otherwise I wouldn't participate in this discussion and I hope you wouldn't either if you didn't expect to sometimes learn something or be confronted with a new idea.

I just find both attitudes "it's making us immortal" as well as "I'm so experienced, I know that no new technology ever lives up to expectations and can mock people who admit they don't know that" unproductive. You don't know. Most technologies don't live up to expectations, a few work out even much better than expected. I'm sure before the Lee Sedol match, you thought to yourself "right, so it's going to win this and then plateau exactly a decade later"?

Even experienced engineers can be surprisingly bad at this. Not everyone can tell their boss “That’s a stupid requirement and here’s why. Did you actually mean …” when their paycheck feels on the line.

The higher you get in your career, the more that conversation is the job.

They just want a yes-bot.

I think that the more you find ways to (productively) make that conversation your job, the higher you get in your career.

[edit] In other words, llms that lie less will be more valuable for certain people, therefore llms that tell you when you are dumb will eventually win in those circles, regardless of how bruising it is to the user's ego.

This is what people never understand about no coding solutions. There is still a process that takes time to develop things, and you will inevitably have people become experts at that process who can be paid to do it much better and quicker than the average person.

It applies outside of tech too. Even if you can make potato pave at home, having it at a restaurant by someone who has made it thousands of times everyday, is preferred. Especially when you want a specific alteration

The out put was verbose, but it tried and then corrected me

> Actually, let me clarify something important: what you've described - "every point equidistant from the center" - is actually the definition of a circle, not a square!

here's the prompt

> use ascii art, can you make me an image of a square where every point is equidistant from the center?

If we're just looking for clever solutions, the set of equidistant points in the manhattan metric is a square. No clarifications needed until the client inevitably rejects the smart-ass approach.

The task has been set; the soul weeps

> On two occasions I have been asked, — "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" In one case a member of the Upper, and in the other a member of the Lower, House put this question. I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.

From Passages from the Life of a Philosopher (1864), ch. 5 "Difference Engine No. 1"

They are either asking: is the machine capable of genuine thought, and therefore capable of proactively spotting an error in the input and fixing it? Or, they were asking: how sensitive is the output to incorrect permutations in the input (ie., how reliable is it)?

I sometimes take them to be asking the former question, as when someone asks, "Is the capital of France, paree?" and one responds, "Yes, it's spoken by the french like paree, but written Paris"

But they could equally mean, "is the output merely a probable consequence of the input, or is the machine deductively reliable"

Babbage, understanding the machine as a pure mechanism is oblivious to either possibility, yet very much inclined to sell it as a kind of thinking engine -- which would require, at least, both capacities

And go and read accounts of the time on "the thinking machine", and the like.

I have no idea what you are going on about.

My view arises from the accounts of people who spoke to Babbage and his interactions with the government, press and similar. He would often dramatically overpromise on what his inventions, always incomplete, could do -- and leave people "hyped". The phrase "thinking machine" was one iirc, lovelace engaged with in order to at once speculate on the many ways the machine will perform (never did, nor could), and caution against an exaggerated interpretation.

However, much evidence by people who interacted with babbage show he was far less cautious than lovelace in order to have the government pay vast sums to fund his engineering. Though, no doubt, towards the end of his life when he's writing a philosophical autobiography -- and has no inventions to show anyone -- he's somewhat more reserved about these accomplishments, and indeed, goes far to include many irrelevant others to pad his CV.

Forgive me for finding his oblivious contempt expressed towards the politicians who were funding his enterprise rather less than charming. It's today a quote trotted out by people very similar to babbage, and this says quite a lot.

So to see you again using such smug language on another thread, proclaiming unsubstantiated conclusions and refusing to reconsider your position when faced with counterevidence or to otherwise provide solid, direct evidence of your own, while calling someone else smug, is equal parts amusing and concerning. If you think smugness leads to confusion, I think it's time to reevaluate your own approach to discourse.

Perhaps I should more proactively split the interaction in my head, "is this a political expression?" or "is this, say, an academic expression?" (here, I'm def., politics: concerned with the who-and-why of belief, over its content). The problem for people like me is that they're often closely related, and we're in positions in which we're surrounded by a kind of politics we didn't consent to.

In particular, the discursive environment of, say computer science, is pathological to the literal and honest use of language. I find the "politics of computer science" qua the people, attitudes, approaches, etc. of the discourse to be basically dishonest. This, i think, is a case very easily made today especially. I used to think it was merely corporate hype, but it actually runs all the way down to fantasist researchers whose preference for fantastical metaphor grossly exceeds their capacity for good faith communication.

So Babbage in having peddled his ideas for money back then, and gualling quoted in his oblivious tone, is a totem for this issue. He was not so extreme as we see today, for sure; but did not hesitate to use the misapprehensions of his benefactors for money. I dislike how readily he is quoted on this.

In any case, I am not always well composed in a climate I find basically dishonest, that's for sure. I'll censor myself more in the future on this. And perhaps I should just finally give up caring about this issue, and consign this disappointment as one more in the bin of nihilism: the "science" of computers is a schizophrenic hall of mirrors where people play bad-faith games with language and incredulous onlookers take up these games and proceed sincerely. What content there is to the innovation is buried, what might be said honestly about it, nearly impossible to discern -- and so on. Very well.

I'd say I thought physicists and philosophers were above it, but string theorists did play similar games in the 90s -- and I was angry all the way through the popsci of that too.

If you're tired of discussing something, maybe it's fine to just let it go and let someone else handle it. But you come off a bit unapproachable when you bring negative energy into the conversation. This is a place where we can learn from each other, a forum, not a battlefield. Positivity opens minds, negativity shuts them. It's not any one person's fault if you've encountered their ideas before, and besides, you might be wrong sometimes, as we all are.

I'm sure you'll share some relevant quotes from these accounts any day now then

You put in 2+2, and 4 comes out. That's the right answer.

If you put in 1+1, which are the wrong figures for the question of 2+2, will 4 still come out? It's easy to make a machine that always says 4.

What an absurdly elegant way of saying one can't comprehend the stupidity behind some questions.

Given those requirements, I would draw a square on the surface of a sphere, making each point of the square equidistant from the sphere's center.

We can argue that AI can do this or that, or that it can't do this or that. But what is the alternative that is better? There often isn't one. We have already been through this repeatedly in areas such as cloud computing. Running you own servers is leaner, but then you have to acquire servers, data centers and operations. Which is hard. While cloud computing has become easy.

In another story here there are many defending that HN is simple [0]. Then it is noted that it might be getting stale [1]. Unsurprisingly as the simple nature of HN doesn't offer much over asking an LLM. There are things an LLM can't do, but HN doesn't do much of that.

For people to be better we actually need people. Who have housing, education and healthcare. And good technologies that can deliver performance, robustness and security. But HN is full of excuses why those things aren't needed, and that is something that AI can match. And it doesn't have to be that good to do it.

[0] https://news.ycombinator.com/item?id=44099357 [1] https://news.ycombinator.com/item?id=44101473

It's not just on HN; there's a lot of faith in the belief that eventually AI will enable enlightened individuals infinite leverage that doesn't hinge on pesky Other People. All they need to do is trust the AI, and embrace the exponentials.

Calls for the democratization of art also fall under this. Part of what develops one's artistic taste is the long march of building skills, constantly refining, and continually trying to outdo yourself. In other words: The Work. If you believe that only the output matters, then you're missing out on the journey that confers your artistic voice.

If people had felt they had sufficient leverage over their own lives, they wouldn't need to be praying to the machine gods for it.

That's a much harder problem for sure. But I don't see AI solving that.

In my experience this is always the hardest part of the job, but it's definitely not what a lot of developers enjoy (or even consider to be their responsibility).

I think it's true that there will always be room for developers-who-are-also-basically-product-managers, because success for a lot of projects will boil down to really understanding the stakeholders on a personal level.

I see two variants of the "please hear me, I have good ideas" effect: positive and negative:

1) This looks great, have you thought about adding <seemingly cool sounding thing that is either impossible to implement or wouldn't actually be useful in the real world>?

And

2) Oh no! Aren't you worried about <breaking something in some strange edge case in some ill advised workflow that no real world person would ever use>?

"I'll look into it" is a great answer. Heaven help the poor LLMs who have to take all this stuff seriously and literally...

But its a lie if you don't do it. In some other cultures you teach people to accept that their complaint isn't important rather than teach programmers to lie, and those people accept it since its normal there to deny complaints.

I don't think its healthy for a culture to force lies like that.

I realize that the value of this approach is highly dependent on a culture of public respect. Common in Japan, and common in some cultures in the U.S. Making the wrong person look stupid is a recipe for career problems in those cultures.

There's also an art to it in how you frame the response, figuring out what the clients really want, and coming up with something that gets them 90% there w/o mushrooming app complexity. Good luck with AI on that.

In my personal experience there’s no substitute to building relationships if you’re an individual or small company looking for contract/freelance work.

It starts slow, but when you’re doing good work and maintain relationships you‘ll be swimming in work eventually.

Often personal relationships with companies that employed me in the past, or companies where ex-colleagues worked.

The only single time I did freelance work for anyone else was when my neighbour (a graphic designer) sent some work my way.

Much better is variations of "We could do that, but it would take X weeks and/or cost this much in expenses/performance.

This leads to a conversation that enlightens both parties. It may even result in you understanding why and how the request is good after all.

Product wanted it done in 6 months, to which I countered that the timeframe was highly unlikely no matter how many devs could be onboarded. We then proceeded to do weekly scope reduction meetings. After a month we got to a place where we comfortably felt a team of 5 could knock it out... ended up cutting the number of bugs down only marginally as stability was a core need, but the features were reduced to only 5.

Never once did I push back and say something wasn't a good idea, much of what happened was giving high level estimates, and if something was considered important enough, spending a few hours to a few days doing preliminary design work for a feature to better hone in on the effort. It was all details regarding difficultly/scope/risk to engender trust that the estimates were correct, and to let product pick and choose what were the most important things to address.

Onus is yours to explain the difficulty and ideally the other party decides their own request is unreasonable, once you’ve provided an unreasonable timeline to match.

Actually straight-up saying no is always more difficult because if you’re not actually a decision-maker then what you’re doing is probably nonsense. You’re either going to have to explain yourself anyways (and it’s best explained with an unreasonable timeline), or be removed from the process.

It’s also often the case that the requestor has tried to imagine himself in your shoes in an attempt to better explain his goals, and comes up with some overly complex solution — and describes that solution instead of the original goal. Your goal with absurd requests is to pierce that veil and reach the original problem, and then work back to construct a reasonable solution to it

It’s not just about time or budget, at all. Some things are downright impossible without the appropriate data.

I mention this above but: I was recently in a situation where a PM wanted two calls to a pure mathematical function to have the same result even though the inputs were different.

I can patiently explain this multiple times and provide alternatives and try to explore the actual problem space, but it comes a point that the PM saying “maybe I should ask another engineer” becomes grating enough to make you want to quit.

Working with people who not only are unable to do their jobs but also refuse to listen to others has become too normalized in this industry.

> Working with people who not only are unable to do their jobs but also refuse to listen to others has become too normalized in this industry.

In parts of it, sure. But there really are places with higher quality of people. You will have to prove yourself a bit more to get hired there, of course.

What you're implying here is extremely disrespectful and uncalled for. This phrase alone says much more about you than it does about me.

The point of my story is that taking cheap shots at your interlocutor isn't the way to build software, or win discussions. Let's at least aim to be a bit more respectful towards each other here.

I hope the fact that you need good skills to get good jobs is not controversial.

I meant this as a message of hope: There really are good jobs out there, so don't give up on the industry!

However: even joining companies with amazing engineering departments, salaries and even great executive departments is not a guarantee that the software making process is at the same level. I say this with experience in one FAANG, two YC startups and two multi-billion-dollar unicorns.

There is a fundamental disdain towards both developers and users in the industry, visible on one side by the RTO/layoffs/AI-replacement, and on the other with dark patterns, cookie-banners, autoplay videos, behavioral experimentation and recklessness with data and general slowness.

I still maintain that saying "no" to things that damage the world and compromise the work is the duty of anyone calling themselves an engineer.

Finally, a Microsoft FrontPage for the 2020's

"control-freak" not necessary. For any known sequence/set of feature requirements it is possible to choose an optimal abstraction.

It's also possible to order the requirements in such a way, that introduction of next requirement will entirely invalidate an abstraction, chosen for the previously introduced requirements.

Most of the humans have trouble recovering from such a case. Those who do succeed are called senior software engineers.

Until a level of absolutely massive scale, modern tooling and code and systems reasonably built can handle most things technically, so it usually comes down to minimizing complexity as the #1 thing you can do to optimize development. And that could be

- code design complexity - design complexity - product complexity - communication complexity - org complexity

And sometimes minimizing these ARE mutually exclusive (most times not, and in an ideal world never… but humans...) which is why much of our job is to all push back and trade off against complexity in order to minimize it. With the understanding that there are pieces of complexity so inherent in a person/company/code/whatever’s processes that in the short term you learn to work around/with it in order to move forward at all, but hopefully in the long term make strategic decisions along the way to phase it out

Haven't we found a better term for that yet?

It is intentional, designed complexity...

There's no accident about it: engineers or management chose it.

Recent discussion on accidental versus essential (kicked off by a flagged article): https://news.ycombinator.com/item?id=44090302 (choosing good dichotomies is difficult, since there's always exceptions to both categories)

I don’t really care for the name but I care about grifters pretending it doesn’t really exist.