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.

▲

varjag 5 hours ago | parent | next [-]

Nope, coding was still the hard bit. Every failing programmer would jump into architects or prod management but not the opposite way.

▲

luke5441 3 hours ago | parent | next [-]

Coding just often has a fast feedback loop. If you can't do it people are going to notice pretty fast. You can fail as an architect or prod management for a long time before people discover you are not good at it.

One thing that is good to have in all those positions is an understanding of the code base and where it can slowly evolve to and how that positions the code base best in the market. I'd say the best way to build this understanding is still to build parts of the system yourself. Not talk to experts or agents about the code base.

	▲	varjag 3 hours ago \| parent [-]
		Yup you'd fail fast because you could not at the time bullshit and handwave the computer. When you don't do the implementation work itself your sloppiness is mostly the concern and inconvenience of implementors. And I concur the best way to understand the system is through the code, and the best way to understand the code is to write it. We aren't going to understand the systems we whackchitect from now on. It's the endless prodding and begging instead, something that makes me infinitely sad.

▲

nemothekid 2 hours ago | parent | prev | next [-]

>jump into architects or prod management but not the opposite way.

This has nothing to do with any intrinsic difficulty with coding and more to do with the industries penchant to rewrite everything every couple of years. The reason you don't see people who went to management become ICs again, is because you have to spend time learning the new, correct™, way to do read and write code.

From the constant API churn for something like React, or even the 20 million updates to write "modern" C++, someone who has had those minute decisions abstracted away will struggle to write code.

▲

pjmlp 4 hours ago | parent | prev [-]

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.

	▲	varjag 4 hours ago \| parent [-]
		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.

▲

ozgrakkurt 2 hours ago | parent | prev | next [-]

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

▲

d0mine 2 hours ago | parent | prev | next [-]

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.

▲

skydhash 5 hours ago | parent | prev [-]

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.