I do ask AI a lot of questions, but it would be good to have a non-AI frame of reference that I can rely on. I find that having a structured starting point really helps me challenge and evaluate some of the outputs.
I do ask AI a lot of questions, but it would be good to have a non-AI frame of reference that I can rely on. I find that having a structured starting point really helps me challenge and evaluate some of the outputs.
21 comments
Using AI is not a bad thing in itself, but you should treat it as an assistant rather than a crutch. When AI gives you an answer, ask yourself "why this approach?" and evaluate the response critically from multiple angles. When you build with that mindset, you naturally develop good architecture instincts, both by understanding the AI's reasoning and by pushing back on it.
Personally I would recommend starting with a Discord bot. I started learning programming by building a discord bot with dashboard before ChatGPT existed, and looking back it was a surprisingly good way to develop architecture sense. The scope is flexible, even if it is built just for yourself, it can grow as complex as you want. You can keep adding features over time, and every new feature forces you to think about how it fits into what already exists. And that friction is where the learning actually happens.
These are available to read completely free online, but I do plan to purchase the physical books some day.
[edit] I realize that I should probably give more context to my answer. The books on the site are basically interviews with the authors of the software and they discuss what choices they made as well as the advantages/tradeoffs of this approach. In other words, the direct answer to your question is to learn by reading what other people have written about their own successes and glean from that.
[edit 2] Your favorite LLM could also provide a list of books that are similar in spirit, but there's just something about the series that I linked to that I like.
There is no “best way”, it always depends on what you are building.
The main advice I would give is to always remember that there’s trade-off’s in every architectural choice…
I guess some general tenants might be… “great architectural solutions…”
- Allow new features to be added, without much complexity
- Have reliable and clear abstraction layers
- Allow tests and typing to validate it’s correctness
- Manage clearly understood limitations, rather than implicit surprise limitations
I second the comment (https://news.ycombinator.com/item?id=48327571) recommending How to Design Programs (HTDP) and Structure and Interpretation of Computer Programs (SICP). The former has an edX course (https://www.edx.org/learn/coding/university-of-british-colum... and https://www.edx.org/learn/coding/university-of-british-colum...) and the latter has online lectures (https://www.youtube.com/watch?v=-J_xL4IGhJA&list=PLE18841CAB...)
Head First Architecture (https://www.amazon.com/Head-First-Software-Architecture-Arch...) is good.
Reading about systems thinking would be useful.
Learning programming languages that have been well designed is helpful. I suggest Programming Erlang: Software for a Concurrent World and Elixir in Action.
Every architectural decision is a tradeoff between something and another. Every technology choice is also a tradeoff. If you understand the reasons for the choices you'll start understanding architecture.
Sometimes it starts with requirements (ie: what you're trying to do), or what your deployment environment looks like, your hosting provider, or even what technology static you'd rather use.
For example, I'd never use Java for a project ever again; it's unclear what it really brings to the table, and it's more difficult to deploy on AWS. And if I was going to use Java I wouldn't pick Spring or any other dependency injection framework because they inevitably lead to impossible-to-debug performance issues. I wouldn't use an ORM for the same reason. No Ruby as well, due to issues with migrations and active record. No postgres unless there was a specific feature of it that works better than other, due to RDBMS management overhead and inconsistencies.
Of course, now that I write this my next project is going to be some random Java/Spring/pgsql thing with a Ruby engine attached (aargh).
What helps actually is reading the "why you should use this tool" parts of each tool. You can start building a mental model/checklist of the good/bad things of each one and why would you use one instead of the other. There's almost always more than one tool available, and the way you deploy/scale/manage/backup each one will tell you a lot about when you would (or wouldn't) use it.
In general don't worry about scale until you're at the point you can test for scalability. I mean, some architectures are better than others, but all of them will be performant at 10 users. Even flat files, a bash web server, and bash-based CGIs can handle 10 users.
When I'm building with AI now, it's much faster, yeah, but it's extremely difficult to learn these patterns, so I feel like slowing down the pace when working with LLMs (although very difficult), and researching things properly will allow you to develop these muscles, and bring benefits in the long run.