Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Great Programmers (2004)

bramcohen.livejournal.com

Post reply on HN
Print view View original

21–30 of 31 posts

Re: Great Programmers (2004)

#21

Post by ianopolous »

jliechti1 wrote: post #6

Does anyone have any good resources for learning how to better architect systems? Other than, say, The Architecture of Open Source Applications: http://aosabook.org/en/index.html Reading source code of prominent projects is a good way to get better, but it's hard to understand the architecture if you aren't aware of the design constraints/requirements that led it to be the way. Surely there must be a way to fast trac…

This is a good book, though a few years old now: Beautiful Architecture: Leading Thinkers Reveal the Hidden Beauty in Software Design (http://shop.oreilly.com/product/9780596517984.do) Disclaimer: I'm the lead developer for one of the featured projects (though wasn't at the time).

Re: Great Programmers (2004)

#22

Post by stiff »

jliechti1 wrote: post #6

Does anyone have any good resources for learning how to better architect systems? Other than, say, The Architecture of Open Source Applications: http://aosabook.org/en/index.html Reading source code of prominent projects is a good way to get better, but it's hard to understand the architecture if you aren't aware of the design constraints/requirements that led it to be the way. Surely there must be a way to fast trac…

Take a task of some inherent complexity but that can still be coded in 10-20 pages of code or less, create one solution, and then try out various different versions of it, or even complete rewrites, changing coding style, decomposition into modules, performance tradeoffs taken, data structures chosen and so forth, and then compare those with respect to length, code clarity, create benchmarks, etc.

Example projects: ray tracer, hash table (way more choices and trade-offs to be made than you would expect), toy grep, toy pseudo-pascal or lisp compiler, basic web crawler, ... It's hard, but you will learn a ton. Even putting substantial effort into improving a one page program, incubating and trying out ideas over a few days, can be beneficial if there is some "meat" in that program to chew on.

In general I believe software architecture is much more low level and less philosophical than a most aspiring architects believe. It's really about knowing the trade-offs of a decision before making it, and this rests on knowing a lot about data structures, algorithms, existing components (like databases, operating systems) etc. Those little programs in non-trivial problem areas often already show up a lot of those things.

Re: Great Programmers (2004)

#23

Post by bcbrown »

jliechti1 wrote: post #6

Does anyone have any good resources for learning how to better architect systems? Other than, say, The Architecture of Open Source Applications: http://aosabook.org/en/index.html Reading source code of prominent projects is a good way to get better, but it's hard to understand the architecture if you aren't aware of the design constraints/requirements that led it to be the way. Surely there must be a way to fast trac…

How is that book? It looks really interesting.

Re: Great Programmers (2004)

#24

Post by tieTYT »

> My suggestion for learning software architecture is to practice. Obviously you can't practice it by doing hundreds of projects, because each one of them takes too long, but you can easily design a hundred architectures for problems which only exist on paper, and where you strive to just get the solution to work on paper.

But, how do you get feedback to tell you if you're making the right or wrong decisions?

Re: Great Programmers (2004)

#25

Post by thatthatis »

jliechti1 wrote: post #6

Does anyone have any good resources for learning how to better architect systems? Other than, say, The Architecture of Open Source Applications: http://aosabook.org/en/index.html Reading source code of prominent projects is a good way to get better, but it's hard to understand the architecture if you aren't aware of the design constraints/requirements that led it to be the way. Surely there must be a way to fast trac…

It applies to all creative work, but I've had good experience with "forced alternatives." That is to say, Forcing myself or my team to come up with three options for architecture even if the first one seems to work. The process often leads to great instead of good outcomes because in scenarios 2 and 3 you're free to moon-shoot as you have the safety net of a workable option #1.

Re: Great Programmers (2004)

#26

Post by jude- »

jliechti1 wrote: post #6

Does anyone have any good resources for learning how to better architect systems? Other than, say, The Architecture of Open Source Applications: http://aosabook.org/en/index.html Reading source code of prominent projects is a good way to get better, but it's hard to understand the architecture if you aren't aware of the design constraints/requirements that led it to be the way. Surely there must be a way to fast trac…

One strategy I've found works for me is to keep a document explaining why you designed the system the way you did. What were the alternative possibilities? Why didn't you pursue them instead? Do so without referencing projects or implementation details, and derive your reasoning from first principles.

I revisit the document as I'm working on a project, so when I go to code a new feature, I make sure I can justify the need to create it with respect to the larger design of the system it lives in.

Re: Great Programmers (2004)

#27

Post by EdwardCoffin »

jude- wrote: post #26
jliechti1 wrote: post #6

Does anyone have any good resources for learning how to better architect systems? Other than, say, The Architecture of Open Source Applications: http://aosabook.org/en/index.html Reading source code of prominent projects is a good way to get better, but it's hard to understand the architecture if you aren't aware of the design constraints/requirements that led it to be the way. Surely there must be a way to fast trac…

One strategy I've found works for me is to keep a document explaining why you designed the system the way you did. What were the alternative possibilities? Why didn't you pursue them instead? Do so without referencing projects or implementation details, and derive your reasoning from first principles. I revisit the document as I'm working on a project, so when I go to code a new feature, I make sure I can justify the…

This reminds me of a tip Guy Steele gave in his talk on the Language Design panel of the Dynamic Languages Wizards Series in 2001 [1]. He said: It's important to establish design principles early on, that is in effect to do meta-design, because as you evolve the design, or as the language grows later, you want to remain true to an initial vision. This has to do with keeping the description small, and if you can resort to a meta-principle to help you resolve a particular design decision, it keeps the language more consistent. (17:09-17:29) [2]

[1] http://www.youtube.com/watch?v=agw-wlHGi0E

[2] http://www.youtube.com/watch?v=agw-wlHGi0E#t=17m09s

Re: Great Programmers (2004)

#28

Post by dustingetz »

jliechti1 wrote: post #6

Does anyone have any good resources for learning how to better architect systems? Other than, say, The Architecture of Open Source Applications: http://aosabook.org/en/index.html Reading source code of prominent projects is a good way to get better, but it's hard to understand the architecture if you aren't aware of the design constraints/requirements that led it to be the way. Surely there must be a way to fast trac…

It would be faster to be mentored by (/work with) someone who knows how to architect systems. The better your mentor, the better you will be. If one thinks he is already good enough at architecting systems, obviously he will not improve very quickly. There is always someone better.

Re: Great Programmers (2004)

#29

Post by tomsthumb »

jliechti1 wrote: post #6

Does anyone have any good resources for learning how to better architect systems? Other than, say, The Architecture of Open Source Applications: http://aosabook.org/en/index.html Reading source code of prominent projects is a good way to get better, but it's hard to understand the architecture if you aren't aware of the design constraints/requirements that led it to be the way. Surely there must be a way to fast trac…

I found this delightful: http://aosabook.org/en/index.html

Re: Great Programmers (2004)

#30

Post by jude- »

EdwardCoffin wrote: post #27
jude- wrote: post #26

Earlier quoted context omitted.

One strategy I've found works for me is to keep a document explaining why you designed the system the way you did. What were the alternative possibilities? Why didn't you pursue them instead? Do so without referencing projects or implementation details, and derive your reasoning from first principles. I revisit the document as I'm working on a project, so when I go to code a new feature, I make sure I can justify the…

This reminds me of a tip Guy Steele gave in his talk on the Language Design panel of the Dynamic Languages Wizards Series in 2001 [1]. He said: It's important to establish design principles early on, that is in effect to do meta-design, because as you evolve the design, or as the language grows later, you want to remain true to an initial vision. This has to do with keeping the description small, and if you can resor…

I didn't know about those videos. Thanks for the links!
Post reply on HN