But I'd say in my oh 10-15 years of programming I've learned that the way to really learn the importance of a pattern is by deriving why it is really needed. You can't really make shortcuts there.
The difference with software is that it's soft. We're not actually creating buildings. Yes we ship products so it's related. But it's more on the spectrum towards disciplined writing or math than architecture in the traditional sense.
It's actually more to your advantage to learn via practicing with the minimum tools for the job.
Anyway, still important to learn others' patterns. But it's less meaningful in terms of how it fits in your mind -- in particular, knowing when to apply them in the future -- than deriving them on your own.
And there's less risk in learning via mistakes unlike with building physical things. Software just has faster iterations.
- Designing software in minute detail beforehand is generally neither necessary nor possible.
- It is impossible for someone to be a capable software "architect" unless they are an experienced software "builder".
- It is impossible for someone to be a capable software "builder" unless they are also capable of designing it.
- Software can be reused once built, and this matters while building it.
- Software is rarely "finished", but continues to grow over time.
- Software can be used by an unbounded number of users at the same time.
- Software can be reproduced infinitely.
- Software can be forked and incrementally changed.
- Anyone can design and build their own software, given some talent and a computer.
- The business motivations for software development are fluid, and often change rapidly over the course of a single project.
I could go on and on. As with many (most?) metaphors, it offers some superficial familiarity, but is ultimately harmful to your understanding.
Software is software. Understand it by reading about software and writing software.
edit: to be more specific about the top three; the first rests on the word "minute" which can be as large or small as you want, depending on what you're trying to prove. The second may be true now, but that's largely because we lack a specific language of high-level software abstraction, so the only way to learn it is to build a lot of things (the general point of the original passage, btw.) The third is just wrong - plenty of people are useful for building parts of software who would have no ability to design a large application. I suspect that those people are a majority of the industry.
In context here, "minute detail" is obviously a relative term comparing the requirements of software and architecture design.
You just made up the "specific language" thing. The reason we don't get unicorns to write software for us is they don't exist either.
There are many incompetent software devs out there, but I don't see how anyone can possibly build any amount of software _well_ without having an appreciation of how to design it. This is why I used the word "capable".
The thing is, even if some of these things were similar to architecture, it would be by accident. They are, on the surface, totally different fields. On a deeper level, they're still totally different. The onus is on you to show the linkage, if you believe it to be applicable.
I used to work for a top5 consulting engineer - architects some times just do the very high level design the consulting engineers actually turn this into a practicable design which is then built by the contractors and the navvy's.
And I am sure that my dept boss Dr Shair (one of the pioneers of the cable stay bridge design) would consider him self an engineer and not an architect
I was going to reply about experience (and code review) being the best teacher, but this is better. Critics from your peers are good, but critics from the experts are even better.
"Architects look at thousands of buildings during their training, and study critiques of those buildings written by masters. In contrast, most software developers only ever get to know a handful of large programs well—usually programs they wrote themselves—and never study the great programs of history. As a result, they repeat one another's mistakes rather than building on one another's successes.
"Our goal is to change that. In these two books, the authors of four dozen open source applications explain how their software is structured, and why. What are each program's major components? How do they interact? And what did their builders learn during their development? In answering these questions, the contributors to these books provide unique insights into how they think.
"If you are a junior developer, and want to learn how your more experienced colleagues think, these books are the place to start. If you are an intermediate or senior developer, and want to see how your peers have solved hard design problems, these books can help you too."
edit: a major advantage to aosa is that all the source is available.