I don't know how to build software and you don't either

While I appreciate the author's humility, I don't appreciate them putting it on to me. These questions have answers, just not the ones the author is looking for. The answer is the process. You take your context, your objectives, your team, and do what makes sense. And time changes all things, so constantly re-adjust. I prefer statically typed languages, but are you wrong to choose Python if that's what you and your team is most comfortable with? Absolutely not, if your goal is to deliver something using the knowledge you have now. I think the author is looking for a static answer: X is always right. And that isn't reality. It isn't reality in engineering, in art, and in play, all of which software can be done as an activity.

(40 years building software)<p>I think the most significant aspect of building software that is rarely discussed is the business’s appetite for change.<p>I can solve any architecture problem, but I can’t lead a horse to water.<p>By far the biggest hurdle to building good software is gaining buy-in and trust from everyone.<p>The actual architecture is like skiing a double black diamond. If you’re at that level of skiing, you can ski anywhere.

If there is any guideline I follow, it is that any complexity must be justified.<p>When for a client we have a choice in hosting environment, we still choose Windows because a shared IIS hosting environment or Az App Service in both cases allow deployment though MSDeploy and don&#x27;t require docker because on Windows you can run many apps side-by-side without issue. This saves a whole lot of hassle.<p>For frontend, any library or build system needs to be justified. No webpack because it causes more problems than it solves. A simple gulp build suffices.<p>In terms of software architecture, a simple webapp-database architecture works fine for 80% of the use cases. No need to introduce extra parts with extra complexity. Boring architectures work best. Any complexity can and will be a source of headaches.<p>I could go on and on.

I like this idea. I think we can dismiss the most literal&#x2F;extreme interpretation of this (as most commenters seem to be doing), but when I look at most of us I find we are more likely to forecast with overconfidence than underconfidence (tech X will destroy the company, or NOT using x will destroy the company).<p>I remember working at a place and our whole data-team (myself included) seemed like a useless waste a dozen engineers. I thought the company was adrift. A few years later it was bought for billions of dollars because the business people knew exactly how to threaten a dominant player in the market. And I realized my henny-penny attitude was complete noise, I just was out-of-the-loop about what the long-term play was.<p>I think a lot of this is that we each want to be the center of our own universe, we want <i>our</i> problems to be the <i>THE</i> problems, and to some degree understand that peddling our advice about tech X or Y is to some degree advancing our own influence.

In the end, this is a question of judgement.<p>Everyone doing senior work in any field is doing judgement. What are the pros and cons of doing this thing? What are the short and long term consequences?<p>There&#x27;s not actually that much we can generalise about judgement itself. Did you think about it, considering all the tradeoffs? Did things work out?<p>So a lot of the high level advice I see in the Internet is basically just turning the same stones over and over.<p>I feel like the most useful articles are actually about specific things like how to write a memory allocator. Those are more like sharing experience that can be used as the raw material of making good decisions.

Maybe not me but I feel like someone knows how to build software on this site?

I’d like to challenge a core argument of the article:<p>&gt; Only your last ~20 years of experience matters for these questions, because the basic landscape of software development changes so rapidly. [...]<p>… with an anecdote. I’ve recently skimmed through a “Thinking Forth” book, and, language-specific information apart, was surprised to read that the software structure they recommend resembles to what I’ve figured out over years of programming by intuition.

This is nihilistic nonsense. The author&#x27;s problem is that he&#x27;s only ever seemingly worked on web stuff. People stay in their domain far too often and then come up with big statements like &quot;I have 20 years of experience and don&#x27;t know what I&#x27;m doing.&quot; Is that maybe because you stick around a domain and layer defined by people with an average 2 years of experience, many of whom learned their job from a Youtube tutorial?<p>It&#x27;s possible for organizations to get better, even good at building software. The foundations of the field haven&#x27;t changed much, people just don&#x27;t learn about them and go on to build towers of overwrought abstraction, which is the thing that keeps constantly changing.<p>If you think of React and Redux as foundational, then everything you say has water under it. Go open a TCP socket.

I don&#x27;t like the assumption of the author you must have observed these architectures in action. Nor does he think you can learn from a 4 year old architecture that was in place when you joined the company. Nor can you read books and papers published about companies&#x27; architectures.<p>He touches on this point only to reinforce that you can only learn by experience, which is at least partially incorrect, even if I agree its a fantastic teacher.<p>It&#x27;s a nice bit in humility and a reminder of the length of time it takes to reveal major effects of architecture decisions but it paints a bit of a false hopelessness.

This reminds me a lot of my feelings for Wayland color management being ready to ship color management. <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=42284035">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=42284035</a><p>A lot of software does take a lot of trying &amp; stumbling through to get good.<p>Alas many companies simply allow the rubble to build up around them, are on to new features, rather than figuring out how better to stitch their systems together after the first bad pass or two. Sure, X11 was there... it wasn&#x27;t good. Trying to be more than haphazard takes work, and time.

I don&#x27;t like the assumption of the author you must have observed these architectures in action. Nor does he think you can learn from a 4 year old architecture that was already in place when you joined the company. Nor can you read books and papers about lessons learned published by other companies.<p>It&#x27;s a nice reminder to be humble and at the length it takes to see major effects from architecture decisions but he paints a kind of hopeless picture that just isn&#x27;t there.

The author argues against absolutism in SWE, but makes absolute claims about experience requirements to understand what he’s talking about.

These pseudo humble tirades are getting tiring. Just grow a backbone and own decisions that you make, Jesus.<p>And I do know how to build software. Whatever narrow definition I have of it.<p>And no, this is not coming out of defensiveness but frustration.

This is why consulting is such an awesome career path once you have some experience under your belt. It is absolutely possible to be well-informed enough to answer these questions, because consultants see the beginning, middle and end of these decisions!

All of these calls about which way to build software are judgment calls.<p>For example - a monolith has strong benefits but when you reach a certain size &amp; team size it makes sense to split out some things - but you should still keep the monolith where it makes sense. And redux state storage makes sense for 99% of cases but the org should have flexibility to let teams run things their own way if they can make their case, depending what controls your org wants to have in place to keep a certain level of standardization. It’s about finding a balance.<p>The author seeks universal answers where none exist. All these different approaches have survived well enough to enter the zeitgeist so they each must have merit. The fact they’re contradictory suggests the appropriate mental model is more like a flowchart with many end states, than a path that seeks a holy grail.<p>I also strongly counter the author’s assertion that 20 years is not enough time to see all this play out. Of my 20 years’ software dev experience, 5 were at a company that went from less than 2000 employees to over 40000 while I was there. I saw the architecture evolve to meet the challenges of growth through many orders of magnitude of scale, and saw the hiring of people who’d done the thing in other companies at the level we needed and brought the leadership to implement it within our teams. 20 years is absolutely enough time to get in one of these 5 year experiences even if the other 15 years is throwaway. To maximize your chances, go and work in SF or Silicon Valley. Yes, it does happen elsewhere in the world; but with far less regularity. If you really want to hone your craft you have to go to the place it’s happening.

This is a dumb post. I can&#x27;t believe someone with 20 years is still looking for X is better than Y, black-and-white answers. All these questions have answers, but they&#x27;re not blanket ones. You have to get into the details. But even without getting into details, I could probably ask ChatGPT and with a short conversation get to the crux of each matter. Most of them come up frequently enough on HN to have stock answers that the author doesn&#x27;t seem to know about.<p>Microservices? It&#x27;s about parallelizing and scaling teams. By decoupling codebases, tech stacks, deployments (to a large degree), you lean into Conway&#x27;s law and reap benefits with other costs like dealing with eventually consistent behaviour.<p>Typed vs Untyped languages? Answer is use the language you know when starting out. A lot can be done with either, in most cases it comes down to preference and adeptness of what you know. For large-scale standard software (e.g. database, API, front-ends) using a statically-typed language will allow larger groups of developers to work on the same codebase with fewer surprises (like a typo in an unexercised codepath). But the sunk-cost is not a fallacy (or is very high so tread carefully), you can&#x27;t stop and rewrite your entire business in Rust and compete to survive.<p>Blah blah blah...<p>Even if you work at each company for several years at a time, if you&#x27;re paying attention you can see that a thing they did many years ago is tech debt on current development and operation. You don&#x27;t have to learn in real-time, learn past history of the codebase you&#x27;re working in. If you only work at early startups, try something different...<p>Like what some other comments are saying, try different things, expand your horizons, gain a wider perspective than what folks who are doing exactly what you&#x27;re doing are talking about. Most of this focus on code and packaging is <i>plumbing</i> as far as I&#x27;m concerned. The actual thing software does is transform data from one thing to another: datastructures, algorithms. A higher level view, databases and SQL. The other stuff is a moderate puzzle of filling in the blanks.<p>Stop trying to find answers by appealing to authorities, f#@*-around and find out.<p><i>Edit: I actually entered this into GPT-4o and got expected results.</i><p><i>&quot;The following is a post on Hacker News. I want you to look at the examples of unknown things given, and for each one, get to the crux of the matter providing a concise why&#x2F;why-not, when&#x2F;when-not, pros&#x2F;cons.</i><p><i>...&quot;</i>