6 ms·

Great Programmers (2004)

111 points by jenningsjason 12y ago

AndrewDucker 12y ago
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?"
mef 12y ago
Note this is from 2004.
webmaven 12y ago
Title should probably have [2004] added to it.
qwerta 12y ago
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.
- deleted 12y ago
  [deleted]
- collyw 12y ago
  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 12y ago
    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 12y ago
      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.
jliechti1 12y ago
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.
- xfax 12y ago
  In my experience, there is no better way than to build it. You learn quickly from your failures and become aware of subtle issues that no text-book or article will ever touch since they are so domain specific. 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.
  - floppydisk 12y ago
    parent has some great points. You only will really learn by doing. 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.
- highCs 12y ago
  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.
krupan 12y ago
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 12y ago
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).
LeicaLatte 12y ago
TLDR; Try to find as many different approaches as they can, once they have found a working solution.
notacoward 12y ago
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.
hyp0 12y ago
Redefine the problem. A change in perspective is worth 80 IQ points. - Alan Kay
leorocky 12y ago
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.
deleted 12y ago
[deleted]
tieTYT 12y ago
> 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?

111 points by jenningsjason 12y ago

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

mef 12y ago

Note this is from 2004.

webmaven 12y ago

Title should probably have [2004] added to it.

qwerta 12y ago

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.

deleted 12y ago
[deleted]
collyw 12y ago
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 12y ago
  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 12y ago
    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.

jliechti1 12y ago

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.

xfax 12y ago
In my experience, there is no better way than to build it. You learn quickly from your failures and become aware of subtle issues that no text-book or article will ever touch since they are so domain specific. 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.
- floppydisk 12y ago
  parent has some great points. You only will really learn by doing. 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.
highCs 12y ago
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.

krupan 12y ago

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 12y ago

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

LeicaLatte 12y ago

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

notacoward 12y ago

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.

hyp0 12y ago

Redefine the problem. A change in perspective is worth 80 IQ points. - Alan Kay

leorocky 12y ago

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.

deleted 12y ago

[deleted]

tieTYT 12y ago

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