> This is such marketing speak. The words mean nothing, they’re just a vague amalgamation of feelings. “Vibes”, if you will.
I actually think this reveals more about you than you might realise. A _lot_ of people enjoy being able to help people resolve problems with their skills. Delivering value is marketing speak, but it's specifically helping people in ways that's valuable.
A lot of people who work in software are internally motivated by this. The act of producing code may (or may not be) also enjoyable, but the ultimate internal motivation is to hand over something that helps others (and the external motivation is obviously dollars and cents).
There is also a subset of people who enjoy the process of writing code for its own sake, but it's a minority of developers (and dropping all the time as tooling - including LLMs - opens development to more people).
> If you are using LLMs to write your code, by definition your product isn’t “polished”. Polishing means pouring over every detail with care to ensure perfection.
You can say the same thing about libraries, interpreters, OSes, compilers, microcode, assembly. If you're not flipping bits directly in CPU registers, your not pouring over every little detail to ensure perfection. The only difference between you and the vibe coder who's never written a single LoC is the level of abstraction you're working at.
Edit:
> If you “love delivering value and solutions”, go donate and volunteer at a food bank, there’s no need for code at any point.
I also think this says maybe a lot about you, also, as many people also donate their time and efforts to others. I think it may be worth some self-reflection to see whether your cynicism has become nihilism.
I have spent over a decade working primarily on open-source, for free. I still do it, thought it’s no longer my primary activity. A huge chunk of that time was helping and tutoring people. That I still do and I’m better at it; I still regularly get thank you messages from people I assisted or who use the tools I build.
I did use to volunteer at a food bank, but I used that example only because it’s quick and simple, no shade on anyone who doesn’t. I stopped for logistical reasons when COVID hit.
I have used the set of skills I’m god at to help several people with their goals (most were friends, some were acquaintances) who later told me I changed their life for the better. A few I no longer speak to, and that’s OK.
Oh, and before I became a developer, I worked in an area which was very close to marketing. Which was the reason I stopped.
So yeah, I know pretty well what I’m talking about. Helping others is an explicit goal of mine that I derive satisfaction from. I’d never describe it as “delivering value/solutions” and neither would any of the people I ever helped, because that’s vague corporate soulless speech.
I don’t think they should’ve done that or continue to do it without consent, and I don’t limit that to code. Books, images, everything else applies the same.
I also don’t think “but it wouldn’t be viable otherwise” is a valid defence.
I don’t see what that has to do with the conversation, though. If your point is about the free/$20, that doesn’t really factor into my answer.
> So yeah, I know pretty well what I’m talking about. Helping others is an explicit goal of mine that I derive satisfaction from. I’d never describe it as “delivering value/solutions”, that’s vague corporate soulless speech.
While I commend your voluntary efforts, I don't think it lends any more weight to your original comment. In fact, I think this comment highlights a deep cynicism and I think a profound misunderstanding of the internal motivations of others and why "delivering value" resonates with others, but rings hollow to you.
In the end, this debate is less about LLMs, and more about how different developers identify. If you consider software to be a craft, then mastery of the skillset, discipline, and authorship of the code is key to you.
If you consider software to be a means to an end, then the importance lies in the impact the software has on others, irrespective to how it's produced.
While you are clearly in the former camp, it is undeniable that impact is determined entirely by what the software enables for others, not by how it was produced. Most users never see the code, never care how it was written, and judge it only by whether it solves their problem.
You’re failing to understand the complaint is about the hollow term being used to sound grandiose.
A street sweeper “delivers value” in the form of a clean street. A lunch lady at a school “delivers solutions” in the form of reducing hunger in children.
There’s nothing wrong with wanting to do something for others, the criticism is of the vague terminology. The marketing speak. I’ve said that so many times, I’d hope that’d been clear.
> While you are clearly in the former camp
You’re starting from wrong assumptions. No, I’m not “in the former camp”, I find the whole premise to be a false dichotomy to begin with. Reality is a spectrum, not a binary choice. It’s perfectly congruent to believe a great product for customers is the goal, and that the way to achieve it is through care and deliberate attention to the things you do.
> You’re failing to understand the complaint is about the hollow term being used to sound grandiose.
This isn’t a critique of language - it’s a category error. You’re confusing the mechanism with the purpose.
In your examples, a street sweeper or lunch lady (Google says this is an antiquated US term for canteen worker?) do indeed deliver value, clean streets and nourished students. That's the value they're paid to provide. Those are the outcomes we care about, and whether the sweeper uses a broom or Bucher Citycat is only of interest in that one allows the sweeper to provide more value at lower cost, eg more metres of clean road per dollar.
The same is true of the canteen worker, who may use Rationales and bains marie to serve more hot meals at lower cost than cooking each meal individually.
> You don’t “deliver solutions”, you write software (or have it written for you).
Saying you "write software", not deliver solutions actually indicates that you don't understand the profession you're in. It mistakes the process for the outcome. Writing code is one means among many for achieving an outcome, and if the same outcome could be achieved by the business without software, the software would be dropped instantly. Not because care doesn’t matter, but because the purpose was never the code itself.
> It’s perfectly congruent to believe a great product for customers is the goal, and that the way to achieve it is through care and deliberate attention to the things you do.
But according to you, care and deliberate attention (software as craft) are the only way. An absolutist position. But most software that matters is imperfect, build over time, touched by many hands, and full of compromises. Yet it still delivers enormous value. That’s evidence that outcomes, not purity of process, is what delivers value and defines success in the real world.
> Writing code is one means among many for achieving an outcome, and if the same outcome could be achieved by the business without software, the software would be dropped instantly. Not because care doesn’t matter, but because the purpose was never the code itself.
Early in my career I was called in a number of times to write software for some business process. Many times after talking to the users and understanding the process, I would recommend against any software. It wasn't needed, or the time could be spent in better ways (AI is likely changing that calculation though). IIRC, my title was even 'Solutions Provider' or some such. I love writing software, but it's always been a means to an end for me.
> But according to you, care and deliberate attention (software as craft) are the only way. An absolutist position.
No! That is not what I’m saying! How can you argue my position is an absolute when I just explicitly described it as a spectrum?!
However, I do believe you’re arguing in good faith, I just don’t think we’re on the same page. I wish we were, as while I think we might still disagree, I also believe we’d have an interesting conversation. Probably more so in person.
Unfortunately, I have to go get some work done so I’m unable to continue as of now. Still, instead of leaving you hanging, I wanted to thank you for the respectful conversation as well as your patience and I believe genuine effort in trying to understand my position.
> If so, you should make all generated code your code, exactly in the form it needs to be according to your deep expertise.
Is this also true of all third party code used by their solution? Should they make all libraries and APIs they use their own in exactly in the form it needs to be according to their deep expertise? If not, why not?
If so, does this extend to the rest of the stack? Interpreters, OSes, drivers? If not, why not?
Well, what if one becomes unmaintained or has issues that only affect your project. Why is that uncontrolled code different to generated code? Is it specifically that it's generated?
This isn't a trick question, BTW. It's a genuine attempt to get to the rationale behind your (and the GP's) stance on this.
In particular, the GP said:
> Or to phrase it more succinctly: if you are in camp 2 but don't have the passion of camp 1, you are a threat for the long term.
That hints I think at their rationale, that their stance is based on placing importance on the parts of software development that they enjoy, rather than any logical basis.
> Well, what if one becomes unmaintained or has issues that only affect your project.
This happens, but very rarely compared to changes in your own code base. If a library breaks, you can usually find an alternative, but even in that case you need to know how to modify your own code.
The difference with generated code is that you are tasked to maintain the generated code.
The EU average passenger car fleet age is 12.5 years.
> From what I understand even considering battery mining and using dirty electrical generation, you’re still at breakeven within a couple years of driving with an EV.
Only when compared to buying a new ICE, as it takes 1-2 years average mileage in the US and 2-4 years in the EU for a new EV to reach emissions parity with a new ICE. It takes well over a decade in the EU for a new EV to recover it's production emissions va driving an existing used ICE. It's never environmentally friendly to scrap an ICE for a new EV.
The average length of ownership is a pretty warped statistic, though. It is dependent on when in the car's life cycle someone buys it. At one end of the market are new car buyers who keep them longer than average, at the other end are people who constantly buy end-of-life junkers for $500.
Those must be US estimates involving huge mileage, because - taking your existing ICE car's production emissions as an already sunk cost - replacing an existing ICE with a new EV would over a decade of driving the average EU mileage (~10k km) before reaching emissions parity.
It takes 2-4 years of that mileage alone for a new EV to reach lifetime emissions parity with a new ICE in the EU (which I know is longer than the US due to the vast differences in average emissions per vehicle between the two continents).
For most of the world, the GP is correct. Driving whatever car you have will always be more environmentally friendly than buying a new EV. Reduce and reuse are environmental cornerstones for a reason.
People keep their cars for longer than 2 to 4 years and an EV sold in 2 to 4 years will likely be driven by someone else.
Which is why I put a used EV as being better for the environment vs a new one.
But both will be better for the environment in their lifetime than keeping a used ICE on the road.
It's more economical to keep your current car until it starts seeing major mechanical issues. However, environmentally an EV will (almost) always beat an ICE, the sooner you get one the better. Especially in a place like the EU where you can get even more environmentally friendly EVs due to the lower amounts of driving. You can, for example, grab the BYD seagull which has a 30kWh battery pack. That alone significantly reduces the new EV environmental impact beyond what some of the older numbers would have shown.
> However, environmentally an EV will (almost) always beat an ICE, the sooner you get one the better. Especially in a place like the EU where you can get even more environmentally friendly EVs due to the lower amounts of driving.
This is simply not true. A new EV will not reach emissions parity with a used ICE car in its average useful lifetime (12.5 years).
This isn't close or controversial, so I wonder what the basis for your mistaken belief otherwise is? Not even EV companies make this claim.
The payoff period for an EV is anywhere from 15,000 to 25,000mi. The moment any EV crosses that threshold, it becomes better for the environment than the ICE vehicle that you'd otherwise buy.
If your used ICE vehicle has 15 to 25,000mi in it, then yeah, replacing it with an EV today is the better choice. It's more a matter of when it will be the better choice.
This is only not true if you have very low yearly milages or a particularly efficient ICE. Which, maybe you do.
> The payoff period for an EV is anywhere from 15,000 to 25,000mi. The moment any EV crosses that threshold, it becomes better for the environment than the ICE vehicle that you'd otherwise buy.
That's the payoff period for the carbon differential between a new EV and a new ICE, not a new EV and your existing ICE, where the carbon cost of production is already sunk. Hence why the GP commented that keeping your ICE is environmentally better than buying a new EV.
Also note that 15-25k miles is 24-40k km, or 2.4-4 years of the average annual mileage in the EU. That's to break even with a new ICE. To break even with a second hand ICE, it's on the order or 15-20 years, or effectively longer than the useful life of the EV.
> If your used ICE vehicle has 15 to 25,000mi in it, then yeah, replacing it with an EV today is the better choice. It's more a matter of when it will be the better choice.
This claim is simply false. There is no point in the lifetime of a used ICE where replacing it with a new EV will result in reduce overall emissions.
From the ICCT, ironically under the subtitle "Addressing misuse of data in the EV debate":
> One common claim is that electric vehicles have higher emissions associated with battery manufacturing. While manufacturing emissions for battery electric cars are roughly 40% higher than for gasoline cars, the ICCT’s research shows that this initial “emissions debt” is typically offset after around 17,000 kilometers of driving, usually within the first one to two years of use in Europe.
The emissions debt is relative to a new ICE.
In cradle-to-grave emissions, electric cars are much lower than ICE cars in lifetime carbon footprint, often 50% lower.
That doesn't change the fact the replacing a used ICE with a new EV will result in increased overall emissions and increase the net carbon footprint.
> I'd love to see a source that says otherwise. I think you have a bad source for the CO2 emissions of new EV production.
This is a completely uncontroversial fact and no environmental or governmental bodies make the claim which you are putting forward, so I'd rather like to see your sources.
So I'm looking at the given graphs in your linked article and I just don't see how you are coming up with the 12 and 20 year timeframes for payback of EVs.
Just fuzzy eyeballing (I don't see the actual numbers for the manufacturing estimated CO2, just the graph), it looks like ~10% of the lifetime emissions for a new ICE come from manufacturing. That would put the the new EV payback vs used ICE at 4 or 5 years.
At that point, it just sort of depends on how long you hold onto your ICE for.
> This would be escalated to upper management to find out why people are under so much time pressure that they need to take calls in the bathroom, and at the very least doing so would be made some kind of violation of new policy.
Or why there are people so idle that they can defecate without working.
Remember, HR protects the company, and complaints about heavy hitters because they work on porcelain aren't going to reflect well on the complainant.
Yes, that old chestnut. It's such insanely toxic advice too.
You're correct that HR is there to protect the company. The original post did not specify "heavy hitters", nor did I ever say to make an accusatory report. HR doesn't have to specifically know who is taking their calls this way.
I'm sorry if you or others have had such bad experiences with the most basic of HR interactions, though if I assume you're taking your own advice I doubt you've ever tried.
There's the tactful way to do this, and then there's whining to HR. I would be very careful taking advice from whiners because they're the ones who keep propagating this bad faith myth about HR.
All I'm saying to do is notify them about ongoing behavior with an emphasis on how it probably makes the company look bad and that it's done by many. They don't care who is doing it and it's not personal. I'd honestly be very surprised if this behavior doesn't already fall under some existing policy.
> I'm sorry if you or others have had such bad experiences with the most basic of HR interactions, though if I assume you're taking your own advice I doubt you've ever tried
I use HR to protect my company from people like you.
It's exactly as I suspected. The only people spreading the toxic advice about HR are the ones who benefit most from making the workplace suck for everyone else.
I can only hope you just think HR is there to insulate you this way and haven't had to test it, because it simply isn't. You really don't want to be on the losing end of a wrongful termination suit. It's only because people rarely bother that you may not have come across one of those. Then it then escalates to worse when all of HR spills their guts about the pressure they were under to protect higher ups.
There is no loyalty after all. It's just a job to everyone else.
Yes, this is a classic example of a programmer (or data scientist in this case) believing their expertise in one areas generalises to topics which they don't fully understand.
The great thing about the internet for now is that anyone can chime in, but anytime you find yourself wiring something like "I don't see why", it may be time for a deeper dive to see if the why is well founded.
This completely overstates the problem, is not supported by the evidence, and is exactly the kind of alarmism that undermines genuine climate science.
An AMOC slowdown or even collapse does not trigger an ice age. Full glacial periods are driven by orbital forcing, not ocean circulation alone.
The evidence points to regional cooling of a few degrees in parts of Western and Northern Europe, not rendering everything north of France uninhabitable.
Past ice sheets advanced over millennia under much colder global conditions than today, not on human timescales.
Even severe AMOC scenarios would be major and costly disruptions, not close to Europe being wiped off the map.
Companies don't care about you or any other developer. You shouldn't care about them or their future well-being.
> Because this cost is implicit and not explicit it doesn’t occur to them.
Your arrogance and naiveté blinds you to the fact it is does occur to them, but because they have a better understanding of the world and their position in it, they don't care. That's a rational and reasonable position.
>they have a better understanding of the world and their position in it.
Try not to use better/worse when advocating so vociferously.
As described by the parent they are short-term pragmatic, that is all. This discussion can open up into a huge worldview where different groups have strengths and weaknesses based on this axis of pragmatic/idealistic.
"Companies" are not a monolith, both laterally between other companies, and what they are composed of as well. I'd wager the larger management groups can be pragmatic, where the (longer lasting) R&D manager will probably be the most idealistic of the firm, mainly because of seeing the trends of punching the gas without looking at long-term consequences.
No, they just have a different job than I do and they (and you, I suspect) don't understand the difference.
Software engineers are not paid to write code, we're paid to solve problems. Writing code is a byproduct.
Like, my job is "make sure our customers accounts are secure". Sometimes that involves writing code, sometimes it involves drafting policy, sometimes it involves presentations or hashing out ideas. It's on me to figure it out.
> Like, my job is "make sure our customers accounts are secure".
This is naiveté. Secure customer accounts and the work to implement them is tolerated by the business only while it is necessary to increase profits. Your job is not to secure customer accounts, but to spend the least amount of money to produce a level of account security that will not affect the bottom line. If insecure accounts were tolerated or became profitable, that would be the immediate goal and your job description would pivot on a dime.
Failure to understand this means you don't understand your role, employer, or industry.
> Your job is not to secure customer accounts, but to spend the least amount of money to produce a level of account security that will not affect the bottom line
I completely agree with every line of this statement. That is literally the job.
Of course I balance time/cost against risk. That's what engineers do. You don't
make every house into a concrete bunker because it's "safer", that's expensive and unnecessary. You also don't engineer buildings for hurricanes in California. You do secure against earthquakes, because that's a likely risk.
Engineers are paid for our judgement, not our LOC. Like I said.
You can apply the same logic to all technologies, including programming languages, HTTP, cryptography, cameras, etc. Who should decide what's a responsible use?
I actually think this reveals more about you than you might realise. A _lot_ of people enjoy being able to help people resolve problems with their skills. Delivering value is marketing speak, but it's specifically helping people in ways that's valuable.
A lot of people who work in software are internally motivated by this. The act of producing code may (or may not be) also enjoyable, but the ultimate internal motivation is to hand over something that helps others (and the external motivation is obviously dollars and cents).
There is also a subset of people who enjoy the process of writing code for its own sake, but it's a minority of developers (and dropping all the time as tooling - including LLMs - opens development to more people).
> If you are using LLMs to write your code, by definition your product isn’t “polished”. Polishing means pouring over every detail with care to ensure perfection.
You can say the same thing about libraries, interpreters, OSes, compilers, microcode, assembly. If you're not flipping bits directly in CPU registers, your not pouring over every little detail to ensure perfection. The only difference between you and the vibe coder who's never written a single LoC is the level of abstraction you're working at.
Edit:
> If you “love delivering value and solutions”, go donate and volunteer at a food bank, there’s no need for code at any point.
I also think this says maybe a lot about you, also, as many people also donate their time and efforts to others. I think it may be worth some self-reflection to see whether your cynicism has become nihilism.
reply