4 ms·

If it was the easy part, then why did they pay us hundreds of thousands, sometimes millions, sometimes more - to do it? The fact of the matter is that it wasn't

by Aqueous 7mo ago

If it was the easy part, then why did they pay us hundreds of thousands, sometimes millions, sometimes more - to do it? The fact of the matter is that it wasn't easy, not for a brain that's architected the way a human's is. The fact that computers can now do it much more quickly and arguably - in many cases - better doesn't diminish the act itself - it just shows how far AI has come, and how easily human intelligence will be dwarfed as it continues to make progress.

echelon 7mo ago
Folks have little appreciation for how soon we're all about to transition to something new. I don't know what that entails, but something is going to happen. I got into a discussion with some Rust compiler folks yesterday. I called Rust the "final human language we'll serialize our thoughts to": it's easy to write for LLMs, is super type safe, ergonomic, easy for humans to read and reason about, and has really nice deploy characteristics - single binary, no GC, bare metal, etc. If Python and Rust are equivalently easy to emit, you'll probably choose Rust if you're not bound to other choices. People quipped back that this was absurd and that Rust is built for decades of future human use, that this kind of talk would put people off of Rust, and that they need to think of the future. As if anything will be human in the coming decades. Programming languages were punch cards.
- 9rx 7mo ago
  > super type safe Maybe if you're willing to write insanity like this: struct Zero; struct Succ<N>(N); trait Add<Rhs> { type Output; } impl<M> Add<M> for Zero { type Output = M; } impl<N, M> Add<M> for Succ<N> where N: Add<M> { type Output = Succ<<N as Add<M>>::Output>; } But even then it doesn't really work all that well for any practical use and you'll quickly hit a bunch of other roadblocks if you were to actually try to use it. You're pushing Rust to go well beyond what it is designed for. If we're being honest, in the real world you're going to write something like this instead: fn add(a: u32, b: u32) -> u32 { a + b } But then you give up the type safety. So it's not really a type safe language in any meaningful sense. Certainly not compared to languages that are designed to be actually type safe. If your only point of comparison is Javascript, then sure, Rust looks pretty super type safe in comparison to that, but in the grand scheme of things it's not type safe. If it is just as easy to emit a language that is type safe, why Rust?
  - echelon 7mo ago
    We skipped over sum types here and the syntactic sugar that makes them a cut above other languages.
    - 9rx 7mo ago
      Other languages meaning Javascript? Rust doesn't even have proper sum types. Try expressing this Coq sum type in Rust: { x : A & B x } I'll wait. If it is just as easy to emit a language that is type safe, why Rust?
- lelanthran 7mo ago
  > I called Rust the "final human language we'll serialize our thoughts to": it's easy to write for LLMs, is super type safe, ergonomic, easy for humans to read and reason about, and has really nice deploy characteristics - single binary, no GC, bare metal, etc. I think it will go the other way - what use is a language with the poor ergonomics of Rust if humans aren't in the loop?
- nillkiggers1488 7mo ago
  [dead]
- nuckfigga 7mo ago
  [dead]
tdb7893 7mo ago
My experience is that the higher paid someone is generally the less they actually code. I'm sure some places have very difficult code but in my experience there's a reason that engineers fresh out of college mostly code and the highest paid engineers do things like design, planning, and coordination.
analog31 7mo ago
This has always seemed like a paradox to me. Once I got past the initial learning curve, coding seemed easy and fun. But most people can't or won't get past that learning curve, for reasons that I don't think we understand. But if coding were hard, then writing small pieces of code would be as hard as writing big pieces. To make an analogy, playing the violin in tune doesn't get any easier, the shorter the piece that you have to play. Developing software is hard. Some sort of "phase transition" occurs when a project gets big and complex, where coding is no longer what makes it hard. And writing software in a way that is not a net burden to a project or organization is hard, involving not just complexity but humanity. Most smart people in an organization have subtly arranged their affairs so that their career progress doesn't hinge on the success of a software project. I admit that I only say these things as an observer, since I can code all day, but didn't pursue a software development career. I also admit that I'm waiting for AI to handle the second two levels of software development. I'll concede that AI can develop software when The Mythical Man Month no longer reads like it was written yesterday.
- skydhash 7mo ago
  > Some sort of "phase transition" occurs when a project gets big and complex, where coding is no longer what makes it hard. It's in the name. Coding is taking an algorithm specified in some manner (pseudocode, diagrams, natural languages, thoughts,...) and transforming it into a sequence of instructions, statements, and expressions, that can be executed by a machine (either directly or through an automated process). We have solved the coding difficulties on several front with things like programming languages (no need to type opcodes), syntax highlighting, linters, snippets, editors, IDEs,... But someone still have to come up with the "Algorithm", and that's where it's hard. Usually because it's a combination of two sources: The business domain and the technical constraint. That's where people are failing. But we did manage to create a lot of building blocks, like the standard algorithms and their data structures, libraries that provides an abstraction over a subdomain, frameworks that provides a scaffold to the thinking process,... But the developer still have to solve the system. And that system can get complex real quick if he's careless. I do believe if you fail at the coding part, that's easy to fix with a few courses (or books) and some practice time. But the system thinking and the solving part is not easily taught. It's not even related to technology other than the latter being the domain it's exercised.
habinero 7mo ago
Because SWEs don't get paid for code. The code is just one byproduct of making business wants into business reality. We get paid to go figure out how to turn a management wishlist into a reliable money machine.
jppittma 7mo ago
coding is getting your foot in the door to software engineering, which is really like, computer systems engineering. We do so much more than code...
- skydhash 7mo ago
  Software engineering is more information processing engineering. Code is just the shovel with which we build the trench. Everything is about data, and we build the things that control and process the data based on various events according to some wants and needs. LLMs are more like a trench digger with a cat's personality. It can helps in some cases, but are more likely to destroy a field. And good luck if you have some difficult terrain to pass through.
  - jama211 7mo ago
    I really recommend you try LLMs again if you haven’t, the last part is really becoming less and less true every day. But I 100% agree that this does not pose a risk to the software developer for all the other points you mentioned. It will just make that trench digger more useful to the developer that needs it. And they’ll still need someone to drive the digger.
    - skydhash 7mo ago
      LLM is useful just like StackOverflow, Wikipedia, Web Search Engine, Manuals,… are. But automated (which is a pro) and with an hallucination problem (which is a core problem). The others also may contain wrong information, but the risks are lower and not being automated means the risks are not compounded. I personally believe we need more trustable source of information rather than automated way to transform it. Especially for the low hanging fruit of coding, which still require to presolve the problem and put us back at the real reason to have a developer. And one thing that people seems to forget is the wealth of pre-LLM tools to speed up coding. No one uses notepad (from Windows 7) to write code, which is what they keep brandishing as the alternative to their agents and what not.
      - 7mo ago
raw_anon_1111 7mo ago
Most developers in the US are “enterprise” developers working in 2nd tier cities working in banks, government, airlines and unknown startups (including most YC companies) that will never make over $175K inflation adjusted their entire career. Hell the way enterprise developer comp has stagnated over the last decade, they may not see that in nominal terms.
paxys 7mo ago
You aren't paid to write lines of code, you are paid to build, ship and maintain products and services, usually in a complex corporate setting with ambiguous and ever-changing requirements. Code is a very small part of the overall picture. Why do you think in most technical organizations the higest ranking and highest paid engineers generally write the least amount of code (often none)?
- menaerus 7mo ago
  On one such engineer there's hundreds or thousands of others executing the idea into work so your premise about "Code is a very small part of the overall picture" is obviously very wrong. You wouldn't need to hire that many people if that was remotely true.
jama211 7mo ago
They didn’t. No one getting paid that much was getting paid for their code.
jayd16 7mo ago
If they paid us for coding they would pay by LOC but that's not the case.
9rx 7mo ago
Because they could. Try running a business that doesn't have the revenues to support high wages and you'll quickly figure out why you will pay as much as possible every single time: It means you can buy your way out of hiring the riffraff. Why do you think these high paying jobs were premised on weird trivia tests and other things that had absolutely nothing to do with the job? Hint: It was a social test to see if you'd fit in to the culture. There have always been legions of people in India ready and able to write code for practically nothing. It was never hard or expensive. But they didn't fit in socially.

by Aqueous 7mo ago

echelon 7mo ago

Folks have little appreciation for how soon we're all about to transition to something new. I don't know what that entails, but something is going to happen. I got into a discussion with some Rust compiler folks yesterday. I called Rust the "final human language we'll serialize our thoughts to": it's easy to write for LLMs, is super type safe, ergonomic, easy for humans to read and reason about, and has really nice deploy characteristics - single binary, no GC, bare metal, etc. If Python and Rust are equivalently easy to emit, you'll probably choose Rust if you're not bound to other choices. People quipped back that this was absurd and that Rust is built for decades of future human use, that this kind of talk would put people off of Rust, and that they need to think of the future. As if anything will be human in the coming decades. Programming languages were punch cards.

9rx 7mo ago
> super type safe Maybe if you're willing to write insanity like this: struct Zero; struct Succ<N>(N); trait Add<Rhs> { type Output; } impl<M> Add<M> for Zero { type Output = M; } impl<N, M> Add<M> for Succ<N> where N: Add<M> { type Output = Succ<<N as Add<M>>::Output>; } But even then it doesn't really work all that well for any practical use and you'll quickly hit a bunch of other roadblocks if you were to actually try to use it. You're pushing Rust to go well beyond what it is designed for. If we're being honest, in the real world you're going to write something like this instead: fn add(a: u32, b: u32) -> u32 { a + b } But then you give up the type safety. So it's not really a type safe language in any meaningful sense. Certainly not compared to languages that are designed to be actually type safe. If your only point of comparison is Javascript, then sure, Rust looks pretty super type safe in comparison to that, but in the grand scheme of things it's not type safe. If it is just as easy to emit a language that is type safe, why Rust?
- echelon 7mo ago
  We skipped over sum types here and the syntactic sugar that makes them a cut above other languages.
  - 9rx 7mo ago
    Other languages meaning Javascript? Rust doesn't even have proper sum types. Try expressing this Coq sum type in Rust: { x : A & B x } I'll wait. If it is just as easy to emit a language that is type safe, why Rust?
lelanthran 7mo ago
> I called Rust the "final human language we'll serialize our thoughts to": it's easy to write for LLMs, is super type safe, ergonomic, easy for humans to read and reason about, and has really nice deploy characteristics - single binary, no GC, bare metal, etc. I think it will go the other way - what use is a language with the poor ergonomics of Rust if humans aren't in the loop?
nillkiggers1488 7mo ago
[dead]
nuckfigga 7mo ago
[dead]

tdb7893 7mo ago

My experience is that the higher paid someone is generally the less they actually code. I'm sure some places have very difficult code but in my experience there's a reason that engineers fresh out of college mostly code and the highest paid engineers do things like design, planning, and coordination.

analog31 7mo ago

This has always seemed like a paradox to me. Once I got past the initial learning curve, coding seemed easy and fun. But most people can't or won't get past that learning curve, for reasons that I don't think we understand. But if coding were hard, then writing small pieces of code would be as hard as writing big pieces. To make an analogy, playing the violin in tune doesn't get any easier, the shorter the piece that you have to play. Developing software is hard. Some sort of "phase transition" occurs when a project gets big and complex, where coding is no longer what makes it hard. And writing software in a way that is not a net burden to a project or organization is hard, involving not just complexity but humanity. Most smart people in an organization have subtly arranged their affairs so that their career progress doesn't hinge on the success of a software project. I admit that I only say these things as an observer, since I can code all day, but didn't pursue a software development career. I also admit that I'm waiting for AI to handle the second two levels of software development. I'll concede that AI can develop software when The Mythical Man Month no longer reads like it was written yesterday.

skydhash 7mo ago
> Some sort of "phase transition" occurs when a project gets big and complex, where coding is no longer what makes it hard. It's in the name. Coding is taking an algorithm specified in some manner (pseudocode, diagrams, natural languages, thoughts,...) and transforming it into a sequence of instructions, statements, and expressions, that can be executed by a machine (either directly or through an automated process). We have solved the coding difficulties on several front with things like programming languages (no need to type opcodes), syntax highlighting, linters, snippets, editors, IDEs,... But someone still have to come up with the "Algorithm", and that's where it's hard. Usually because it's a combination of two sources: The business domain and the technical constraint. That's where people are failing. But we did manage to create a lot of building blocks, like the standard algorithms and their data structures, libraries that provides an abstraction over a subdomain, frameworks that provides a scaffold to the thinking process,... But the developer still have to solve the system. And that system can get complex real quick if he's careless. I do believe if you fail at the coding part, that's easy to fix with a few courses (or books) and some practice time. But the system thinking and the solving part is not easily taught. It's not even related to technology other than the latter being the domain it's exercised.

habinero 7mo ago

Because SWEs don't get paid for code. The code is just one byproduct of making business wants into business reality. We get paid to go figure out how to turn a management wishlist into a reliable money machine.

jppittma 7mo ago

coding is getting your foot in the door to software engineering, which is really like, computer systems engineering. We do so much more than code...

skydhash 7mo ago
Software engineering is more information processing engineering. Code is just the shovel with which we build the trench. Everything is about data, and we build the things that control and process the data based on various events according to some wants and needs. LLMs are more like a trench digger with a cat's personality. It can helps in some cases, but are more likely to destroy a field. And good luck if you have some difficult terrain to pass through.
- jama211 7mo ago
  I really recommend you try LLMs again if you haven’t, the last part is really becoming less and less true every day. But I 100% agree that this does not pose a risk to the software developer for all the other points you mentioned. It will just make that trench digger more useful to the developer that needs it. And they’ll still need someone to drive the digger.
  - skydhash 7mo ago
    LLM is useful just like StackOverflow, Wikipedia, Web Search Engine, Manuals,… are. But automated (which is a pro) and with an hallucination problem (which is a core problem). The others also may contain wrong information, but the risks are lower and not being automated means the risks are not compounded. I personally believe we need more trustable source of information rather than automated way to transform it. Especially for the low hanging fruit of coding, which still require to presolve the problem and put us back at the real reason to have a developer. And one thing that people seems to forget is the wealth of pre-LLM tools to speed up coding. No one uses notepad (from Windows 7) to write code, which is what they keep brandishing as the alternative to their agents and what not.
    - 7mo ago

raw_anon_1111 7mo ago

Most developers in the US are “enterprise” developers working in 2nd tier cities working in banks, government, airlines and unknown startups (including most YC companies) that will never make over $175K inflation adjusted their entire career. Hell the way enterprise developer comp has stagnated over the last decade, they may not see that in nominal terms.

paxys 7mo ago

You aren't paid to write lines of code, you are paid to build, ship and maintain products and services, usually in a complex corporate setting with ambiguous and ever-changing requirements. Code is a very small part of the overall picture. Why do you think in most technical organizations the higest ranking and highest paid engineers generally write the least amount of code (often none)?

menaerus 7mo ago
On one such engineer there's hundreds or thousands of others executing the idea into work so your premise about "Code is a very small part of the overall picture" is obviously very wrong. You wouldn't need to hire that many people if that was remotely true.

jama211 7mo ago

They didn’t. No one getting paid that much was getting paid for their code.

jayd16 7mo ago

If they paid us for coding they would pay by LOC but that's not the case.

9rx 7mo ago

Because they could. Try running a business that doesn't have the revenues to support high wages and you'll quickly figure out why you will pay as much as possible every single time: It means you can buy your way out of hiring the riffraff. Why do you think these high paying jobs were premised on weird trivia tests and other things that had absolutely nothing to do with the job? Hint: It was a social test to see if you'd fit in to the culture. There have always been legions of people in India ready and able to write code for practically nothing. It was never hard or expensive. But they didn't fit in socially.