Great Programmers (2004)(bramcohen.livejournal.com) |
Great Programmers (2004)(bramcohen.livejournal.com) |
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 track this to some extent. Under the deliberate practice model by Anders Ericsson's (i.e. the 10,000 hour rule), simply reading and understanding code is suboptimal because of the lack of immediate feedback on your understanding. I think it'd be interesting to see tutorials/guides that showed how a system design has changed throughout its history as well as the reasons for those changes.
I beleive that there is one answer to this question which does 80% of the job, it is easy to express and yet in the same time impossible to grasp for so many programmers/managers which leads to so many awful codebase.
As the post says very well: start by thinking about what you would do if you had infinite resources. That's the ideal case. Find a real bottleneck (money, cpu, memory, ?) and rethink your architecture accordingly, find the next real bottleneck and so on.
The best way to learn by doing, IMO, is by joining an organization that works on a large and complex code base. It won't be as exciting as writing new code, but adding to an existing complex system will force you to take into consideration things that you otherwise would not.
A couple of things you can do is start reading up on well designed systems and the gotcha stories. Personally, I track highscalability.com since I spend a lot of time working in distributed systems. They tend to have interesting insights and will link to tech talks and blogs that contain a wealth of information. Also go read up on some of the papers explaining the designs behind systems you use (e.g. Amazon dynamo) and why they made the choices they did. It'll give you some insight into how people measure tradeoffs and figuring out what's important.
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.
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.
"If distributed operation is such a key feature, why is Subversion enjoying the amount of marketplace success it has?"
I find best way to learn is to read existing code. When I find interesting project, I download source code and read it from top to bottom. I may even fix a few bugs before hitting compiler.
A change in perspective is worth 80 IQ points. - Alan Kay
But, how do you get feedback to tell you if you're making the right or wrong decisions?
In relation to the other post about the Core Infrastructure Initiative here, you could use that principle and realize that funding and improving OpenSSL, will still keep things more or less as "secure" as they've been until now. But to truly improve the security of the infrastructure of the Internet, we need to rethink things from scratch, and fund and adopt those, too (in browsers, operating systems, etc).