A tangent, I keep hearing this good base, but I've never seen one, not in the real world.
No projects, unless it's only you working on it, only yourself as the client, and is so rigid in it's scope, it's frankly useless, will have this mythical base. Over time the needs change, there's no sticking to the plan. Often it's a change that requires rethinking a major part. What we loathe as tight coupling was just efficient code with the original requirements.
Then it becomes a time/opportunity cost vs quality loss comparison. Time and opportunity always wins. Why?
Because we live in a world run by humans, who are messy and never sticks to the plan. Our real world systems (bureaucracy , government process, the list goes on) are never fully automated and always leaves gaps for humans to intervene. There's always a special case, an exception.
Perfectly architected code vs code that does the thing have no real world difference. Long term maintainability? Your code doesn't run in a vaccum, it depends on other things, it's output is depended on by other things. Change is real, entropy is real. Even you yourself, you perfect programmer who writes perfect code will succumb eventually and think back on all this with regret. Because you yourself had to choose between time/opportunity vs your ideals and you chose wrong.
It’s not about perfectly architected code. It’s more about code that is factored in such a way that you can extend/tweak it without needing to keep the whole of the system in your head at all times.
It’s fascinating watching the sudden resurgence of interest in software architecture after people are finding it helps LLMs move quickly. It has been similarly beneficial for humans as well. It’s not rocket science. It got maligned because it couldn’t be reduced to an npm package/discrete process that anyone could follow.
I've always been interested in software architecture and upon graduating from university, I was shocked to see the 'Software Architect' title disappear. Software devs have been treating software architecture like phrenology or reading tea leaves.
But those who kept learning and refining their architecture skills during this time look at software very differently.
It's not like the industry has been making small, non-obvious mistakes; they've veen making massive, glaringly obvious mistakes! Anticipating a reasonable range of future requirements in your code and adhering to the basic principles of high-cohesion and loose-coupling is really not that hard.
I'm taken aback whenever I hear someone treating software architecture as some elusive quest akin to 'finding Bigfoot'.
Well-architected code should actually be easy to change wrt. new requirements. The point of keeping the architecture clean while you do this (which will typically require refactoring) is to make future changes similarly viable. In a world run by messy humans, accumulating technical debt is even more of a liability.
A important point though is that llm code generation changes that tradeoff. The time/opportunity cost goes way down while the productivity penalty starts accumulating very fast. Outcomes can diverge very quickly.
> No projects, unless it's only you working on it, only yourself as the client, and is so rigid in it's scope, it's frankly useless, will have this mythical base.
This is naive. I've been building an EMR in the healthcare space for 5 years now as part of an actual provider. We've incrementally released small chunks when they're ready. The codebase I've built is the most consistent codebase I've ever been a part of.
It's bureaucracy AND government process AND constantly changing priorities and regulations and requirements from insurance providers all wrapped up into one. And as such, we have to take our time.
Go and tell the clinicians currently using it that it's not useful. I'm sure they won't agree.
> Perfectly architected code vs code that does the thing have no real world difference
This just flat out isn't true. Just because YOU haven't experience it (and I think you're quite frankly telling on yourself with this) doesn't mean it doesn't exist at all.
> Because you yourself had to choose between time/opportunity vs your ideals and you chose wrong.
Like I said above, you're telling on yourself. I'm not saying I've never been in this situation, but I am saying that it's not the only way to build software.
Lesson learned. Yes you are right. I am indeed a junior, I made that comment when I was tired honestly with a rushed project. There's no delete button, otherwise I'd have deleted it when I cooled off. Thank you for giving me hope that good code is still being made.
> Thank you for giving me hope that good code is still being made.
So I've been on both sides, and it's why I responded. While you are absolutely correct that those situations do exist, I just wanted to point out it's not always that way. And I felt exactly as you did about software in general until I finally found a place or two that wasn't just a cash printing machine.
And it's pretty awesome. I've come to realize burnout is less about the amount of hours you put in and more about what you're doing during those hours.
It's tough, especially in the beginning. Push through it. Get some experience that allows you to be a bit more selective in what you choose, and fingers-crossed you'll find yourself in the same spot. One common denominator in all of the good jobs I've had was that the leadership in those companies (3 of them) were all tech-focused. Could be a coincidence, but it's a pattern I've seen.
No projects, unless it's only you working on it, only yourself as the client, and is so rigid in it's scope, it's frankly useless, will have this mythical base. Over time the needs change, there's no sticking to the plan. Often it's a change that requires rethinking a major part. What we loathe as tight coupling was just efficient code with the original requirements. Then it becomes a time/opportunity cost vs quality loss comparison. Time and opportunity always wins. Why?
Because we live in a world run by humans, who are messy and never sticks to the plan. Our real world systems (bureaucracy , government process, the list goes on) are never fully automated and always leaves gaps for humans to intervene. There's always a special case, an exception.
Perfectly architected code vs code that does the thing have no real world difference. Long term maintainability? Your code doesn't run in a vaccum, it depends on other things, it's output is depended on by other things. Change is real, entropy is real. Even you yourself, you perfect programmer who writes perfect code will succumb eventually and think back on all this with regret. Because you yourself had to choose between time/opportunity vs your ideals and you chose wrong.
Thanks for reading my blog-in-hn comment.