Hacker News new | past | comments | ask | show | jobs | submit
The answer to all these "if coding is easy" questions is that coding isn't programming (to put it in Lamport's terms).

Encoding your ideas into a programming language is easy. Understanding that your ideas are bad is hard.

You have clients with multiple devices connecting to your backend simultaneously, while you mediate their interactions with your partner systems. Their versions might not be up to date. It's a distributed system. When was the last time you cracked open a distributed systems textbook?

When was the last time you built a system and stared reality right in face, that is: - can't trust your clocks - pick 2/3 of CAP - exactly-once delivery impossible - the code will need to be altered and released without downtime - hackers will try to exploit you for fun and profit - your manager doesn't want you wasting time getting the above right

Coding is the easy bit.

Nope, coding was still the hard bit. Every failing programmer would jump into architects or prod management but not the opposite way.
loading story #49225281
loading story #49226226
Usually you don't have an option other than leaving, most organisations don't let seniors keep coding and nothing else.

Either move up the ladder or leave.

Non-coding architects were typically a by-track rather than superiors to ICs. Though I imagine some of them could think they were. Product managers also often don't have proper reports in the sense line managers would.
LLMs can write TLA+ models just fine. It can help even with small mobile apps. Surprisingly, simple TLA models were able to find design/workflow issues almost in every of a few vibe-coded apps I've tried on vacation.
> Encoding your ideas into a programming language is easy.

This is still difficult. Sometimes the programming language or the programming methods you want to use effect how you desing the system on an abstract level.

Those computing ideas (like distributed systems, concurrency and task scheduling) can even be found in even a single program/system. They are often entangled with even broader concepts, like visual layouts, security (authentication, authorization), communication and encryption, control systems, signal processing,… And those are often accidental complexity.

The essential complexity can be easily resolved by talking to domain experts. You will get a nice requirements document afterwards. That’s when the engineering and management concerns appear.