I think a more relevant portion of what Joel what talking about is the 'full stack'/'ductape' programmer. The number of times I've seen people optimizing their for loops instead of their DB queries or their caching mechanisms in a web app is simply astounding. Few people realize that there is far more 'slow' code in the parts they didn't write than the parts they did write.
Think about it, in the 'full stack' of browser -> client -> interweb -> web server -> app server -> db server the little bit of code that you wrote is minuscule compared to what you didn't write. Tune up your TCP stack, tune your webserver, add cache headers, add indexes, etc. Most apps can drastically increase their performance with out even changing a single line of code. And when you're tuning up your code, look for single lines of code to change.
Definite protip in there on debugging with wireshark.
We had a client once that we could only login to their IMAP server but not download mail. A little bit of digging with wireshark and we figured out that he had some old POS router that couldn't handle window scaling. Solution? Turn off window scaling on one of the servers.
"""Think about it, in the 'full stack' of browser -> client -> interweb -> web server -> app server -> db server the little bit of code that you wrote is minuscule compared to what you didn't write."""
This. The old saying "don't prematurely optimize" has never been truer. Too bad it's gotten harder to profile. Unless you write a boring CGI, one-load-per-page site, you're never going to be able to get all of that information server-side. The only way is with browser-based testing frameworks... Sigh.
The House example is horrible. In the show rarely does house diagnose an illness thorough intellectual debugging. In most episodes House sits around and insults his team while they run tests and about 5 minutes from the end he out of nowhere has an epiphany (while talking to Wilson most of the time) which often has little to do with what tests the team ran and he solves the case.
A good article, but intimidating, in a way. And I see this quite a bit in terms of budding programmer advice. It boils down to "you need to read this, and then read that, and then read this," and then the comments section will have even more suggestions for reading.
As I get older, and have kids, I find my ability to sit down and read all of this, and somehow retain it, decreasing. I've recently decided to "get back into" coding (won't go into the history as it isn't tangential to the discussion). I've been having some fun with very, very tiny beginner level programs in Ruby. When I build a list of jobs I would want with Ruby involvement, I find I also need to brush up on my Javascript and learn JQuery. I need to get a full understanding of Git/Github. I should also learn Rails and Sinatra, VIM, and get reacquainted with CSS.
On top of that, it really does seem that C is a requirement to really understand what is happening in Ruby. It seems a lot of things that _why_ wrote for Ruby, he wrote in C.
Then there is all the additional readings, such as in this article, and comments section. All of which seem incredibly legit, but leave me feeling like I will never actually find the time to write code due to all the reading I don't have time to do.
This article emphasises the important of building your baseline knowledge on the aspects that haven't changed since the dark ages (and probably aren't likely to for a while). As opposed to learning the flavor of the month web framework that might be yesterday's news a week from now.
Learning about C and how to use a decent debugger/tracing tool will help you track down exactly where those unhelpful errors are being generated. Learning how to listen in on network traffic will help you find out why the foo you sent is arriving as a bar (or not arriving at all). Learning to use the shell opens up a lot of quick reusable operations and automation possibilities.
The books he listed are old, but certainly valuable. I don't think they're going to suddenly go out of date.
On the other hand, how much more reading will you do when you have to learn a new high level language every month to keep up with the latest trend?
However, I wouldn't let this get in the way of doing what you want to do, which is writing code, I guess. Learn bits and pieces as you need them and I think you will see the benefit. Don't let them weigh you down.
The other side of the coin: I've seen frequent indications (even on HN) that there a hordes of programmers out there that know about almost nothing outside of their web app server, HTTP, and their database of choice. This isn't to say such specialists aren't valuable. Specialists are valuable, but if I see a medical specialist, I want them to have a good grounding in general medical knowledge. Likewise, I would prefer all of my computer colleagues to have basic general knowledge as well. Sometimes such knowledge can avert a disaster.
Yorkshireman #1: "Bah, C programmers. They don't know how good they have it!"
Yorkshireman #2: "When I were t'lad, we'd have to use assembler by hand!"
Yorkshireman #1: "Assembler? Luxury! We never had an assembler. We had to poke the data in by hand!"
Yorkshireman #3: "Poke! Oh what I wouldn't have given for poke! We used to live int' shoebox int' middle of road, and we'd bootstrap the OS using toggle switches on't front of case."
Yorkshireman #4: "Oooh toggles! What I wouldn't have given for toggles. We used to live int' hole int' ground, and all we had to go on were scraps of hard stale bread, on which we'd punch holes and use as hollerith cards!"
Yorkshireman #2: "Holes? Holes? Bliss, oh what I wouldn't have done for holes!"
I've actually programmed an 8-bit processor in binary code by repeatedly flipping 8 metal toggles and pressing a "commit" button.
A roommate of mine in school actually TA'd a programming class where he saw some frustrated students take their IBM punch card stack out of the reader, shuffle it, then put it back in.
How can you spot and truly understand memory leaks without having to manage memory allocation by yourself?
My peers (students) and I have discussed this several times. It's a good example, and we use it to argue for continuing to teach C to new CS students at our school.
(It often seems the CS department is trying to move in the Java + Python, and nothing else, direction)
Another worthy pursuit: buy all of Brian Kernighan's books, not just The C Programming Language. It is well worth the pain of becoming slightly familiar with Fortran and Pascal to read these little gems.
Being familiar with how things work is undoubtedly useful, but I argue if you are an application developer, learning software construction is equally if not more important.
See also: Code Complete, Programming Pearls, and C interfaces and implementations.
I never knew Kernighan wrote a pascal book. (or a version of a book in pascal). Neat. Also ampl seems quire useful, I've written my own versions of some of that stuff in mathematica. It'd be great to have it already done for me.
Why imply that there's pain in becoming familiar with Fortran or Pascal? It's one thing to argue that they may not be the best tool to build a web app with, but I'd argue there's a joy in learning about alternative languages.
I agree that it is good to be a "generalist" or a "full stack programmer". I try to be one myself.
Be careful when you hear these classifications coming from recruiters. Whenever I have heard "generalist" what was meant was "someone who can magically already do everything within our narrow domain of concerns."
I fully agree, but all it really says is, "learn how things actually work, people!" This is still mostly fluff and identity politics, hoping people who know they're old-school will upvote it. Flagged.
Great article. This is why I use and love C++. It will be used for the next 50 years or longer. Learning it (or any other foundational, open source programming language) is a must.
You also owe it to yourself to learn the newer techniques.
The article is true and useful and contains many good pointers, but my god is it annoying when you either misunderstand the concept or take it too far. This kind of rot sets in when you refuse to use a tool or technique for no good reason.
Maybe this is a function of age or, more precisely, maturity level: Young people use bad tools to be 'hardcore', old people use bad tools because they stop learning new ones. Either way, the image I immediately dredge up when someone says 'old-school' in this context is someone writing a program using a machine code debugger instead of getting a decent text editor and development tools. Unless you can actually tell the difference in the resulting output, and I guarantee you almost certainly can't when it's assembler vs debugger, use the best (most likely, newest) tools you can get.
(The above doesn't apply to people doing things a certain way for fun. Heck, I run obsolete OSes on emulated hardware for fun. I just don't confuse that with reality.)
[+] [-] fleitz|15 years ago|reply
Think about it, in the 'full stack' of browser -> client -> interweb -> web server -> app server -> db server the little bit of code that you wrote is minuscule compared to what you didn't write. Tune up your TCP stack, tune your webserver, add cache headers, add indexes, etc. Most apps can drastically increase their performance with out even changing a single line of code. And when you're tuning up your code, look for single lines of code to change.
Definite protip in there on debugging with wireshark.
We had a client once that we could only login to their IMAP server but not download mail. A little bit of digging with wireshark and we figured out that he had some old POS router that couldn't handle window scaling. Solution? Turn off window scaling on one of the servers.
[+] [-] silentbicycle|15 years ago|reply
[+] [-] squeed|15 years ago|reply
[+] [-] reedF211|15 years ago|reply
[+] [-] mfukar|15 years ago|reply
[+] [-] Starmonkey|15 years ago|reply
As I get older, and have kids, I find my ability to sit down and read all of this, and somehow retain it, decreasing. I've recently decided to "get back into" coding (won't go into the history as it isn't tangential to the discussion). I've been having some fun with very, very tiny beginner level programs in Ruby. When I build a list of jobs I would want with Ruby involvement, I find I also need to brush up on my Javascript and learn JQuery. I need to get a full understanding of Git/Github. I should also learn Rails and Sinatra, VIM, and get reacquainted with CSS.
On top of that, it really does seem that C is a requirement to really understand what is happening in Ruby. It seems a lot of things that _why_ wrote for Ruby, he wrote in C.
Then there is all the additional readings, such as in this article, and comments section. All of which seem incredibly legit, but leave me feeling like I will never actually find the time to write code due to all the reading I don't have time to do.
Is there an order of importance with all of this?
[+] [-] stuhacking|15 years ago|reply
Learning about C and how to use a decent debugger/tracing tool will help you track down exactly where those unhelpful errors are being generated. Learning how to listen in on network traffic will help you find out why the foo you sent is arriving as a bar (or not arriving at all). Learning to use the shell opens up a lot of quick reusable operations and automation possibilities.
The books he listed are old, but certainly valuable. I don't think they're going to suddenly go out of date.
On the other hand, how much more reading will you do when you have to learn a new high level language every month to keep up with the latest trend?
However, I wouldn't let this get in the way of doing what you want to do, which is writing code, I guess. Learn bits and pieces as you need them and I think you will see the benefit. Don't let them weigh you down.
[+] [-] stcredzero|15 years ago|reply
[+] [-] moggie|15 years ago|reply
[+] [-] _b8r0|15 years ago|reply
Yorkshireman #2: "When I were t'lad, we'd have to use assembler by hand!"
Yorkshireman #1: "Assembler? Luxury! We never had an assembler. We had to poke the data in by hand!"
Yorkshireman #3: "Poke! Oh what I wouldn't have given for poke! We used to live int' shoebox int' middle of road, and we'd bootstrap the OS using toggle switches on't front of case."
Yorkshireman #4: "Oooh toggles! What I wouldn't have given for toggles. We used to live int' hole int' ground, and all we had to go on were scraps of hard stale bread, on which we'd punch holes and use as hollerith cards!"
Yorkshireman #2: "Holes? Holes? Bliss, oh what I wouldn't have done for holes!"
*shamelessly plagiarised from http://www.youtube.com/watch?v=-eDaSvRO9xA
[+] [-] stcredzero|15 years ago|reply
A roommate of mine in school actually TA'd a programming class where he saw some frustrated students take their IBM punch card stack out of the reader, shuffle it, then put it back in.
[+] [-] unknown|15 years ago|reply
[deleted]
[+] [-] sliverstorm|15 years ago|reply
My peers (students) and I have discussed this several times. It's a good example, and we use it to argue for continuing to teach C to new CS students at our school.
(It often seems the CS department is trying to move in the Java + Python, and nothing else, direction)
[+] [-] angrycoder|15 years ago|reply
Being familiar with how things work is undoubtedly useful, but I argue if you are an application developer, learning software construction is equally if not more important.
See also: Code Complete, Programming Pearls, and C interfaces and implementations.
[+] [-] spitfire|15 years ago|reply
[+] [-] timthorn|15 years ago|reply
[+] [-] torpor|15 years ago|reply
[deleted]
[+] [-] jfm3|15 years ago|reply
Be careful when you hear these classifications coming from recruiters. Whenever I have heard "generalist" what was meant was "someone who can magically already do everything within our narrow domain of concerns."
[+] [-] bryanlarsen|15 years ago|reply
And we had to walk uphill to school both ways.
[+] [-] Murkin|15 years ago|reply
A competent programmer could known the whole stack, down to the micro-controller. (Mainly because there wasn't much stack there..)
* Free love&drugs is #1
[+] [-] bbsabelli|15 years ago|reply
[+] [-] silentbicycle|15 years ago|reply
[+] [-] abyx|15 years ago|reply
Good day!
[+] [-] knieveltech|15 years ago|reply
[+] [-] davidk0101|15 years ago|reply
[+] [-] stcredzero|15 years ago|reply
[+] [-] zby|15 years ago|reply
[+] [-] pnathan|15 years ago|reply
[+] [-] 16s|15 years ago|reply
[+] [-] JonnieCache|15 years ago|reply
[+] [-] derleth|15 years ago|reply
The article is true and useful and contains many good pointers, but my god is it annoying when you either misunderstand the concept or take it too far. This kind of rot sets in when you refuse to use a tool or technique for no good reason.
Maybe this is a function of age or, more precisely, maturity level: Young people use bad tools to be 'hardcore', old people use bad tools because they stop learning new ones. Either way, the image I immediately dredge up when someone says 'old-school' in this context is someone writing a program using a machine code debugger instead of getting a decent text editor and development tools. Unless you can actually tell the difference in the resulting output, and I guarantee you almost certainly can't when it's assembler vs debugger, use the best (most likely, newest) tools you can get.
(The above doesn't apply to people doing things a certain way for fun. Heck, I run obsolete OSes on emulated hardware for fun. I just don't confuse that with reality.)
[+] [-] alphamancer|15 years ago|reply