[Aqueous]

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.

[analog31]

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]

> 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.

[Windchaser]

Or, abbreviated?:

Coding is easy; design is hard(er).

[cosmic_cheese]

Part of it is learning, but it's just as much coming into the right mental models for it.

Programs are just virtual machines assembled from numerous smaller parts, not so different from a bicycle, car, or mechanized assembly line, but that's not at all how I thought of them when I was first getting into writing code. I'm not sure I even had a mental model at that point, or if I did it was too simplistic to build anything useful with. It was after my mind picked up the machine model when I started to become capable of writing code and eventually designing and build software from scratch.

[jayd16]

Honestly, it's not even the learning curve. It's easy. Most people can think precisely enough to program.

The difference is that we enjoy sitting in a chair for ~8 hours a day laying dominoes. A lot of folks do not like that.

[paxys]

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]

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.

[tdb7893]

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.

[echelon]

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.

[lelanthran]

> 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?

[9rx]

> 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]

We skipped over sum types here and the syntactic sugar that makes them a cut above other languages.

[9rx]

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?

[9rx]

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.

[habinero]

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.

[raw_anon_1111]

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.

[jayd16]

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

[jama211]

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

[jppittma]

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]

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]

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]

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.

[jama211]

The hallucination problem has dropped exponentially in recent times in code generation. I can’t even recall a time any of the modern models I’ve used have done it in my recent usage. It’ll still do it in cheap/fast models and in places outside of code generation, but the good models write frankly incredible code, especially if you set them up with feedback loops.