> There is a reason that books like "the staff engineer's path" cover topics such as local maximums, communication, [...]

Why would they cover programming? That's what all the books on programming are for.

Also I see no need for signal processing to make programming a hard problem. Writing correct code is hard. Writing code that makes incorrect code easy to spot and hard to write is hard.

You can be great at local maximums, communication, establishing support for executing a plan or creating alignment on big efforts, and proceeded to still create a ball of mud. Bug ridden, hard to read, hard to debug.

▲

rcxdude 4 hours ago | parent [-]

A buggy big ball of mud that does mostly the right thing is still going to beat a high-quality, carefully architected solution that reliably does the wrong thing, though.

And for a huge amount of code, it's not very hard to make it good enough, because the requirements, once understood, are pretty straightforward and perfect correctness often matters much less than you would think.

	▲	avilay 3 hours ago \| parent [-]
		"carefully architected solution" is not what they are saying. A "buggy big ball of mud" will not generally "do the right thing", if it did, it would not be a "buggy big ball of mud". Straightforward requirements do not imply straightforward solutions. In the early 2000s Facebook wanted a quick way to search for friends updates, a straightforward requirement. Turned out they had to build a full graph DB inside MySQL, not straightforward code at all.