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.
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.
Coding is easy; design is hard(er).
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.
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.
Why do you think in most technical organizations the higest ranking and highest paid engineers generally write the least amount of code (often none)?
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.
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>;
}
fn add(a: u32, b: u32) -> u32 {
a + b
}
If it is just as easy to emit a language that is type safe, why Rust?
If it is just as easy to emit a language that is type safe, why Rust?
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?
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.
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.
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.