[PaybackTony]

This is something I preach often, even at FAANG. Often engineers feel comfortable and in-the-zone when solving for a process. One saying I often delivery is: Engineers often think their job is to build things. That's not the whole story, they build things for _people_.

Nobody cares what your code looks like. Nobody cares what your architecture looks like. As engineers we should worry about creating forgettable experiences (at least in enterprise). They care that it does the job well, with low load times and an easy to use UX. That's it. If you did your job right they'll forget that software helped them do their job or complete their task faster / better because the experience was so seamless they spent the entire time focused on their own goal, and not how to navigate your software to get there. How you get there is irrelevant. Now it's your job as an experienced and intelligent engineer to make quick, thoughtful decisions on how to get your product to where it needs to be so that your _customers_ can create more impact on their own business / lives faster.

[quanticle]

    Nobody cares what your code looks like. Nobody cares what your architecture
    looks like.

… until it breaks. Nobody cared how the FAA NOTAM database was implemented either, until it went down. Part of being a professional engineer is thinking about these things, so your users won't have to.

[adrianmonk]

Nobody cares if your warehouse is neat and clean. Your customers never go in there. They just receive orders that are shipped out of it.

But if your warehouse is a mess, if the aisles of your warehouse are blocked by crates strewn everywhere (that you've been meaning to put away for ages), then it does matter if your warehouse is neat and clean because it takes forever to maneuver your forklift in to retrieve products to ship them out. If your warehouse is disorganized, and you can't find anything when you need it, then it matters.

The real trouble, I think, is when people have reasons to choose not to keep the warehouse organized and functioning smoothly (like workers who see it as drudgery or managers who want workers working on something else) and they try to excuse it by saying, "Our customers never visit."

(I don't think the person above is doing that, incidentally. I think they're just agreeing with the keep your eyes on the prize message.)

[lll-o-lll]

The difference between software and most other forms of engineering is that the internals of software are invisible to everyone but the developers. A manager walks in to the warehouse you describe above and goes “what in the literal hell? No one goes home until we clean this $&@$ up!”. A machine that has been poorly designed looks like a piece crap.

Software, if the UI looks nice the massive tangled mess inside is completely invisible to customer and manager alike. Gross inefficiencies, evil hacks, everything entangled with everything? No one can see it. “Why does it take 3 months for a tiny feature?” “Technical debt”, “ok, you can have 5% of your time budget to sort that out”…

If people could really see the software, viscerally, they would approve budgets to fix it.

[ignoramous]

> If people could really see the software, viscerally, they would approve budgets to fix it.

Tools for this exist; ex: https://semgrep.dev/docs/writing-rules/data-flow/data-flow-o...

I suspect the information overload for any substantially large code base would be such that, non-engineers would look right past the complexity after the enthusiasm wears off.

[8n4vidtmkvmk]

Technical managers do look at code...they often don't really "see" the problems until they try to implement something tho.

[disgruntledphd2]

Yeah the best way to understand software (maybe even the only way) is to try to do something with it.

[pixl97]

Yep, this here.

I work with a product that sees a massive difference in use between the low end customers and the very highest end of customers. For the low end customers it doesn't matter what your architecture is at all. Could be a single small machine in a closet and it would suffice.

For our large customers it matters 100%. They are doing throughput 4 to 5 orders of magnitude higher than our most basic customers per day. They will push NAS and database performance to the limit. Every time we think "eh, no one is going to do that much" our customers come back and prove us wrong. Databases expand to billions and billions of rows. Query performance falls apart. Design decisions lead to lack of ability of horizontal scaling.

And when the systems get to this size the costs of operating the system add up quickly, and if your competitors choices lead to much lower operational costs, then expect to lose customers to them, especially as your product equalizes in capability, or at least meets their set of needs.

[limitedsupply]

The argument is that nobody cares if you use a single file with 10K LOC of outdated JavaScript code or a beautiful Rust library to compute whatever.

Of course customers care about performance - if your app is unusably slow it is going to be an issue.

[hbrn]

The risk of focusing on code and architecture too much is that it will never break. Not because it's very reliable: because you have no users.

Part of being a professional engineer is recognizing that your knowledge is always limited. No matter how much you think about these things, they will always break. Being too careful is as bad as being reckless.

Instead of trying to prevent failure, accept that it's inevitable and make sure you are fast at detecting and fixing.

[AnIdiotOnTheNet]

Forgive me if I'm wrong about this, but it would seem to me that the FAA NOTAM system had orders of magnitude more uptime than literally any product produced by so called "professional" "engineers" at big software companies.

[alfalfasprout]

I think the point still stands but in a different way. The architecture was designed to be quite reliable.

[mardifoufs]

More than google.com? Maybe, but it's close. Also, I'd be surprised if those behind NOTAM were all "professional engineers" since software PEs are pretty rare, relatively speaking. Especially in the US.

[hbrn]

You're comparing database to a service. NOTAM is real-time, google.com is not.

By that standard google.com is always down.

[strken]

It would seem to me that the FAA NOTAM system had professional engineers working on it to produce that uptime.

[discussDev]

If it wasn't then who built it? Or is it the quotes we should focus on.

[bluGill]

Sure, but we do make intentional tradeoffs, at least sometimes.

[nfRfqX5n]

AWS uptime is pretty insane

[barbazoo]

According to their own status page, yes

[ILike42Cookies]

yes, some part of aws somewhere is always online.

fully functional? 7.12.2021 alone was enough to kill that statement for the next few years.

[taeric]

While not wrong, everything breaks at scale. Everything. Anyone that says otherwise is just not interested in talking about where what they built will break.

And note that this is more than just scale of use. It is also scale of development. Keep adding changes to something, and it will break. Stability of application requiring stability of development is just not something we care to admit, that often.

That is, don't hide when/why something will break. But also don't get blinded looking for how to avoid all breakage. If you can, find ways to isolate failures and block off entire sections.

[selcuka]

> everything breaks at scale

This is good advice. You should be aware of who you are building for. Designing your system to run on 100 containers orchestrated by Kubernetes is overkill for your average SaaS MVP, while counting on shell scripts is a recipe for disaster at FAANG scale. Scale matters.

[taeric]

Don't just look at the execution you are building for, but also the team that will be maintaining it. That is, there are several values for "who" that you are building for. Each will have cause for you to reach to more complicated seeming solutions, as you go.

[toast0]

> … until it breaks.

My boss once told me, "[toast0], you can't have that kind of attitude if your shit doesn't work"

Rather than change my attitude, I made sure my shit worked.

[PaybackTony]

My point on this isn't that you should write ugly, unmaintainable code because who cares. It's that, if you're an experienced and intelligent engineer, you're going to do just fine. There's no need to complicate it, get lost in analysis paralysis and so forth. I have seen top engineering teams make software that's hard to maintain with questionable performance as a _result_ of some of the things this article brings up. Often times too much engineering is just as bad as not enough.

Here is how I personally define good software engineering:

- Does it do the job? - Is there low cognitive load in regards to following the code? (Can you jump back in the code in 6 months and get your feet quickly... AKA: Don't over-abstract). - Is it performant? - Can you easily make changes?

If those 4 things are true, the rest doesn't matter from my experience.

[unity1001]

For each case like NOTAM database going down, there are tens of thousands of applications running on the web and outside the web without people obsessing about its architecture.

[nunez]

yeah but that's borrowing trouble.

we can spend ages solving every theoretical.

and to be fair NOTAMs were rock solid until that happened, so if anything this failure was a good thing long-term

[tshaddox]

> Nobody cares what your code looks like. Nobody cares what your architecture looks like. As engineers we should worry about creating forgettable experiences (at least in enterprise). They care that it does the job well, with low load times and an easy to use UX. That's it.

Isn't this sneakily hiding the assumption that what your code and architecture looks like has no effect on how good/fast your product is? That's a pretty common implicit sentiment these days, especially as part of the (valid) sentiment that chasing fad languages/frameworks/tools is not a good idea. But it's pretty clearly not true in general.

[pyrale]

I believe the author's point is that you should care about the relation between your technical decisions and actual benefits for the user. It is true that many technical people develop an appreciation for tech choices that is driven by aesthetics more than by actual impact.

That being said, caring too much about customer success also has its pitfall, businesses can be driven by the present more than by the future, and by low-impact guaranteed results more than high-impact hypothetical risks.

[makeitdouble]

The retort would be that your fellow engineers are also user/consumers of your code.

You’re building code that others will review, run, modify and rely on. They are people too and you should care about them and their needs.

[marcosdumay]

The article is entire about the ways that your code and architecture affects the final product. Really, there is no other thing there than the complete opposite of your complaint.

[brianlong0923]

The next engineer working on the code will care about what it looks like.

[goodoldneon]

Good architecture leads to faster feature development and increased stability, which makes your users happy

[jayd16]

The point is that is just one strategy not the goal.

[thefaux]

> Nobody cares what your code looks like. Nobody cares what your architecture looks like.

Do I not count as somebody? ;)

> Now it's your job as an experienced and intelligent engineer to make quick, thoughtful decisions on how to get your product to where it needs to be so that your _customers_ can create more impact on their own business / lives faster.

Quick and thoughtful are often in tension. Sometimes you really do need to take a step back and take the 10000 foot view and think about your systemic challenges. It may be worth investing in a new architecture that will allow you to iterate faster and make quicker, better decisions in the future. The first instinct should of course always be to try do the smallest thing within the limitations of the current system to deliver customer value, but there are times when you are spending so much time fighting the system, that it is a wise strategic investment to rearchitect. It takes significant maturity as a developer to recognize the difference between this type of investment and hype-driven churn.

There are always going to be the kind of developers (often quite smart and idealistic but relatively inexperienced) who are easily susceptible to hype, discover a shiny new toy and want to rewrite everything in its image. This type of developer can waste a huge amount of time, both their own and of their colleagues, engaging in fruitless technical debate.

Also, it is not just the customer who matters. You as the developer also matter. If you hate the system you are working with so much that you desperately want to rearchitect it, you either should find a way to do that or leave the project/company regardless of whether you are able to provide value for customer.

[achairapart]

This makes perfect sense for founders/c-level people, and owners in general.

But here is the employee paradox: He may sooner or later shift his main focus from customers to his own career. So he reinvents the wheel building the next level hot js framework, start measuring his goals in Github stars and conference bookings...

In short, his tech stack IS the product, again.

[unity1001]

This is one of the best comments ever in HN. Every engineer should understand this. Users don't care about what's behind. They care about whether it works and its easy. All the rest is irrelevant to them. We engineers tend to think 'but if this particular thing X happens in the code/stack and causes this particular problem Y, it will cause a Z% percentage problem and this will affect the user experience'. But in the end, for the overwhelming majority of the cases what ends up happening on the user side ends up being something unnoticeable to the user. Causing a lot of time to be spent for something that the users dont care about.

It feels more like we engineers use such logic of 'better code/application' to justify ourselves doing what we would like to do and build with the code than anything else that is related to the user.

[willio58]

> Nobody cares what your architecture looks like.

This isn't an absolute. Yes, people using your thing don't care about the architecture. But developers sure do. If your system is built in COBOL, you will have a smaller pool of developers who will have an interest in working on it.

[Bukhmanizer]

This isn’t wrong, but I also think it’s not wrong for engineers to overcorrect a bit. It’s a balance.

Pretty much every other incentive in an organization is for product. Its really easy to build things as fast and cheap as possible until you literally can’t anymore because no one understands the code.