> Developers like _writing_ and that gives the most job satisfaction.

Not me. I enjoy figuring out the requirements, the high-level design, and the clever approach that will yield high performance, or reuse of existing libraries, or whatever it is that will make it an elegant solution.

Once I've figured all that out, the actual process of writing code is a total slog. Tracking variables, remembering syntax, trying to think through every edge case, avoiding off-by-one errors. I've gone from being an architect (fun) to slapping bricks together with mortar (boring).

I'm infinitely happier if all that can be done for me, everything is broken out into testable units, the code looks plausibly correct, and the unit tests for each function cover all cases and are demonstrably correct.

▲

pmg101 5 days ago | parent | next [-]

You don't really know if the system design you've architected in your mind is any good though, do you, until you've actually tried coding it. Discovering all the little edge cases at that point is hard work ("a total slog") because it's where you find out where the flaws in your thinking were, and how your beautifully imagined abstractions fall down.

Then after going back and forth between thinking about it and trying to build it a few times, after a while you discover the real solution.

Or at least that's how it's worked for me for a few decades, everyone might be different.

	▲	esafak 4 days ago \| parent [-]
		He did not say he does not iterate! And it is much easier and faster to do when an LLM is involved.

▲

skydhash 5 days ago | parent | prev [-]

> Tracking variables, remembering syntax,

That's why you have short functions so you don't have to track that many variable. And use symbol completion (a standard in many editors).

> trying to think through every edge case, avoiding off-by-one errors.

That is designing, not coding. Sometimes I think of an edge case, but I'm already on a task that I'd like to finish, so I just add a TODO comment. Then at least before I submit the PR, I ripgrep the project for this keyword and other.

Sometimes the best design is done by doing. The tradeoffs become clearer when you have to actually code the solution (too much abstraction, too verbose, unwieldy,...) instead of relying on your mind (everything seems simpler)

▲

crazygringo 5 days ago | parent [-]

You always have variables. Not just at the function level, but at the class level, object level, etc. And it's not about symbol completion, it's about remembering all the obscure differences in built-in function names and which does what.

And no, off-by-one errors and edge cases are firmly part of coding, once you're writing code inside of a function. Edge cases are not "todos", they're correctly handling all possible states.

> Sometimes the best design is done by doing.

I mean, sure go ahead and prototype, rewrite, etc. That doesn't change anything. You can have the AI do that for you too, and then you can re-evaluate and re-design. The point is, I want to be doing that evaluation and re-designing. Not typing all the code and keeping track of loop states and variable conditions and index variables and exit conditions. That stuff is boring as hell, and I've written more than enough to last a lifetime already.

▲

skydhash 4 days ago | parent [-]

> You always have variables. Not just at the function level, but at the class level, object level, etc.

Aka the scope. And the namespace of whatever you want to access. Which is a design problem.

> And it's not about symbol completion, it's about remembering all the obscure differences in built-in function names and which does what

That's what references are for. And some IDEs bring it right alongside the editor. If not, you have online and offline references. You remember them through usage and semantics.

> And no, off-by-one errors and edge cases are firmly part of coding, once you're writing code inside of a function.

It's not. You define the happy path and error cases as part of the specs. But they're generally lacking in precision (full of ambiguities) and only care about the essential complexity. The accidental complexity comes as part of the platform and is also part of the design. Pushing those kind of errors as part of coding is shortsightedness.

> Not typing all the code and keeping track of loop states and variable conditions and index variables and exit conditions. That stuff is boring as hell, and I've written more than enough to last a lifetime already

That is like saying "Not typing all the text and keeping track of words and punctuation and paragraphs and signatures. English is boring as hell and I've written more than enough..."

If you don't like formality, say so. I've never had anyone describe coding as you did. No one things about those stuff that closely. It's like a guitar player complaining about which strings to strike with a finger. Or a race driver complaining about the angle of the steering wheel and having to press the brake.

	▲	crazygringo 4 days ago \| parent [-]
		I don't know what to tell you. Sure there are tools like IDE's to help, but it doesn't help with everything. The simple fact is that I find there's very little creative satisfaction to be found in writing most functions. Once you've done it 10,000 times, it's not exactly fun anymore, I mean unless you're working on some cutting-edge algorithm which is not what we're doing 99.9% of the time. The creative part becomes in the higher level of design, where it's no longer rote. This is the whole reason why people move up into architecture roles, designing systems and libraries and API's instead of writing lines of code. The analogies with guitar players or race car drivers or writers are flawed, because nothing they do is rote. Every note matters, every turn, every phrase. They're about creativity and/or split-second decision making. But when you're writing code, that's just not the case. For anything that's a 10- or 20- line function, there isn't usually much creativity there, 99.99% of the time. You're just translating an idea into code in a straightforward way. So when you say, "Developers like _writing_ and that gives the most job satisfaction." That's just not true. Especially not for many experienced devs. Developers like thinking, in my experience. They like designing, the creative part. Not the writing part. The writing is just the means to the end.