
Great Programmers (2004) - jenningsjason
http://bramcohen.livejournal.com/4563.html
======
jliechti1
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](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 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.

~~~
highCs
_how to better architect systems_

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.

~~~
phektus
This is gold. I remember a quote from a prominent game programmer, I think
it's John Carmack but I'm not sure, that when thinking of an approach to a new
game engine he would start on the basis of an imaginary computer with instant
CPU calculation and infinite memory. I can see the parallels here.

------
notacoward
Bram hints at this, but doesn't quite make it as explicit as I would: the
thing that distinguishes great programmers is the ability to understand _how
the pieces interact_. Anyone can understand how one piece of code works, even
if it's fairly complex. A good programmer can understand how one very complex
piece of code works. However, any modern codebase of any significance is
impossible for _anyone_ to understand as a single monolithic whole. The key
ability is to create a clean mental model of each piece, even if the actual
implementation or interface of that piece is nowhere near so clean, and put
those models together to understand all the "between the cracks" stuff. That's
the key bit of genius behind BitTorrent, for example. It's not that the
individual pieces are so special, but that the emergent behavior of those
pieces interacting with one another is very beneficial.

------
AndrewDucker
Fascinating discussion in the comments about version control. This, in
retrospect, is particularly good:

"If distributed operation is such a key feature, why is Subversion enjoying
the amount of marketplace success it has?"

------
qwerta
Why everyone has to write new code to learn?

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.

~~~
collyw
You need good quality code to begin with. I have had a couple of jobs as a
maintenance programmer for large projects, and the code on one was not
something you could learn from. On the other hand I have been playing about
with some Django third party modules, upgrading them to Python 3 for my
project, and that is code I can learn from.

~~~
qwerta
I started as maintenance programmer. I learned from that and now I just walk
away from bad code, unless I get resources to fix it.

~~~
collyw
One of the jobs was for an investment bank. The job was crap. No one in my
team of 5 lasted much more than a year. And sadly they did have the resources
to hire more developers and address the problem that way. Brute force
recruitment.

------
hyp0
Redefine the problem.

 _A change in perspective is worth 80 IQ points._ \- Alan Kay

------
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?

------
krupan
Thanks for adding the 2004. I wondered why he was still bashing poor
subversion and talking about codeville. Interesting thoughts otherwise. When I
interview potential co-workers I ask what makes good code and it's interesting
to hear the variety of answers. Definitely one of the best interview questions
I have discovered. I think Mr. Cohen would pass my interview :-)

------
higherpurpose
Changing things dramatically for the better always seems to involve
"forgetting what you know", ditching everything, and starting from scratch,
doesn't it?

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).

------
leorocky
I'd also include knowing a lot about computers. Like how they work at a low
level, how they represent numbers, low level networking protocol, how the
operating system interfaces like interrupts, how processes and threads work. A
computer science education really helps, but you'll also have to be able to
solve problems and think about how theory and real physics world collide.

------
mef
Note this is from 2004.

------
webmaven
Title should probably have [2004] added to it.

------
LeicaLatte
TLDR; Try to find as many different approaches as they can, once they have
found a working solution.

