You Owe it to Yourself to be Old-School
codelord.net
codelord.net
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.
An application complains about not being able to find a file, but doesn't report where it looked for it? strace can tell.
Do you want to know why a system call failed, and the app is too crappy to report the error? strace to the rescue!
Of course, if you're lucky you might even have access to dtrace...
shakes fist @ ESRI HQ once again
Oh, the arcane magic of "alias." Then again, there have been times I've seen young people impressed by what amounts to "Row, your boat" played on an actual mandolin.
Web programming has much more in line with systems work than most appreciate.
Are you sure you need a more recently updated alternative?
Do I just not see the link to the repo or is there another project page someplace?
http://www.linuxfoundation.org/collaborate/workgroups/networ...
Thankyou so much. I have been trying to remember the name of these devices for ages.
If you like House (for the medical mystery aspect rather than the snark), you may also like Berton Roueche's writing. _The Medical Detectives_ is a pretty good collection.
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?
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.
Some idea of:
- How computer hardware is put together (from the NAND gate up)
- How computer memory is organized/optimized
(and how the abstractions involved can break down)
- How compilers/interpreters/computer languages work
- How a handful of the most commonly used algorithms work
(and the implications of their time/space complexity)
- How networks are organized and implemented
- What operating systems do, and how that relates to hardware
- Basic security, how exploits work
It's like my sister, who is a choreographer and has an exquisite understanding of physics and geometry -- as it applies to dancers. Yet, as far as I can tell, she's completely unable to generalize this to driving and furniture, though she would benefit greatly if she could overcome this limitation. For one thing, when she's driving the family around in a rented car in Italy, she wouldn't end up straddling the center line every time we go around a blind curve. For another thing, her DIY kitchen table made from salvaged parts wouldn't have 3 inches of shear wobble, and her custom desk made from IKEA parts wouldn't have a huge sag in its center. I know she understands the physical ideas behind static mechanics and diagonal bracing applied to dance. I know she has a knack for spatial geometry, because she can have a half dozen dancers move around between each other, keep them from colliding, get everyone where they need to go for the next move, and make the whole thing look beautiful.
I'm also reminded of that Richard Feynman story about teaching physics in Brazil.
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
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.
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)
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.
Please look at the feature set of Fortran 2008 and say that again with a straight face.
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."
And we had to walk uphill to school both ways.
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
Here's the original HN article where it was mentioned: http://news.ycombinator.com/item?id=2202737
Good day!
Kernighan and Pike's The Practice of Programming covers similar material very well.
And yes, I was a bit overly critical. I'm annoyed by that style of article, not that specific one, sorry.
Seriously, I wonder if these sort of posts make people less likely to use powerful-but-old tools, by further inflating their reputation in a way that makes them seem intimidating. I much prefer the opposite approach, such as in Jack Crenshaw's "Let's Write a Compiler" (http://compilers.iecc.com/crenshaw/) - You can make things complicated if you want, but the basics aren't that hard, and helping people to realize "you can do this, you don't need to be some kind of programmer demigod" is very empowering.
Also, I recommend reading the source to tools you admire - seeing other peoples' dirty hacks can be a good reminder that shipping something useful beats waiting until it's perfect.
When I first got into computers/coding everyone I met was so excited to run into another enthusiast and sharing and collaboration where pretty much the rule. Even the writing from the day seemed to emphasized two types of programmer: skilled and green.
These days everything I read emphasises two types of programmers: ubermensch and the tragically useless, a dichotomy that entirely drops the implication that people in general are trainable in favor of implying there are gods among us and those doomed to merely mortal abilities should do the rest of the industry a favor and take up landscaping professionally.
It probably doesn't help that the ACM, etc. keep a lot of important primary documents locked behind their paywall, either.
I've lost count of the number of times I've seen folks gravitate to the shiniest, most miserably complex high tech tools in the shop simply because they're 1. shiny, 2. high tech, 3. complex. There was a guy in last week who's working on a project he plans on patenting. I watched as he spent over an hour setting up a complex system of jigs and programming one of the CNC milling machines in the shop. Seconds after he set the thing in motion the bit managed to snag his work piece (a small bolt), snatch it out of the jig which it then promptly used to murder his jigging system. I could offer a laundry list of minor mistakes this dude made, (no cutting fluid, incorrect jig material/setup, CNC programming error) but the one big mistake is the most interesting in my mind: he picked the wrong tool for the job. A dead simple drill press and a machinist's vice would have not only been entirely sufficient to the task at hand, going "low tech" would have had him productively drilling parts in less than five minutes.
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.)