alt Hacker NewsIDK, a sufficiently complex consumer or enterprise app winds up having big performance problems if people don't know what they're doing w.r.t. the code they write and how they connect systems together with that code. Those performance problems start out not mattering much, first it impacts one seldom-used part of the site, then another, but that chips away at users and can eventually tank the product. That doesn't even get into writing code such that it can be well-understood and modified easily later. It also says nothing about reducing/fixing bugs.
If you have a site whose performance steadily gets worse and the rate of new features steadily declines and the rate of bugs steadily goes up, then your site/app will probably not have a great future.
All of those things depend on solid code. If staff engineers who are too busy talking and building consensus such that they aren't connected with the actual programming and situation on the ground, then all the talking and consensus-building won't matter.
Replies
I would counter with it's easier to fix bugs, improve performance, pay down technical debt than it is to fix consensus, stakeholder buy-in, and strategic direction. So even though good code, design, and architecture isn't easy it's still the easy part in a relative sense.
Yup. And performance problems don't just bleed the user base, they also slow down development and testing internally, both directly and by nudging developers away from attempting some tests or use cases in the first place.
I can understand when people say the code was the way part, but under the assumption that the system design and architecture are clean, code is high quality or the project is greenfield, and there is proper testing and validation. Then, sure, the lines of code aren't the hardest but that's only because that hardest work was front loaded and given a different name. Even then it's still not always easy.
> IDK, a sufficiently complex consumer or enterprise app winds up having big performance problems if people don't know what they're doing w.r.t. the code they write and how they connect systems together with that code.
I don't think you're really disagreeing with the original sentiment? However, I think you're taking a much broader view of "code" than is intended by the original statement.
In your framing, you're kind of confounding code with architecture. Code is really just the act of making a computer do a thing you want it to do, for some definition of "thing you want it to do". Architecture is more about understanding which things you want the computer to do, and in which ways.
There are a million ways to code a task. That's the "code" the original statement is talking about. Understanding which of those ways is an appropriate way is a separate skill, whether you call it architecture, or something else.
You've really seen a web software product die because of performance issues?
Knowing what to do “wrt the code they write” is directly consequential to knowing what do at all, you proved the original point correct.
> a sufficiently complex consumer or enterprise app winds up having big performance problems if people don't know what they're doing w.r.t. the code they write and how they connect systems together with that code.
On those complex systems in particular the problems start long before any code is written.
A software engineer can create and understand the specs, requirements, design the system, architectural decisions, define everything about that software and data, model everything, failure, performance, operational topics, documents everything, etc. before a single line of code is written, and of course they can write good code. Then there are the coders who patch together chunks of code from Stack Overflow or whatever boilerplate they have in the company's repository. I know every coder likes to call themselves a "software engineer" but there's a world of difference between the two types.
For the first group code was never the hardest part. For the second group there was never any other part.