Slashdot Mirror


Jeremy Allison's Advice to Young Programmers

Hyram Graff writes "Jeremy Allison has written a wonderful piece with advice to young programmers. As someone who's been out of college for just over a year, I find it to be a very insightful piece. Please allow me to say, thanks Mr. Allison!"

101 comments

  1. Impressive, young Skywalker by DrMrLordX · · Score: 1, Offtopic

    Something tells me that account won't last long if you keep that up, but damn, it's been awhile since I've seen anyone audacious enough to post content like that, even as AC.

    Now that you mention it, you DO offer sound advice. All the of the scenarios portrayed therein represent terrible situations which young programmers (or anyone else, really) would do well to avoid. The chain(saw) especially.

    1. Re:Impressive, young Skywalker by JNighthawk · · Score: 3, Informative

      Parent is a troll, as is GP. GP is a link to troll images.

      --
      Wheel in the sky keeps on turnin'.
    2. Re:Impressive, young Skywalker by DrMrLordX · · Score: 1

      Of course, why else would I call him audacious for posting such drivel in the first place? Such blatant trolling is pretty rare nowadays.

    3. Re:Impressive, young Skywalker by JNighthawk · · Score: 1

      Commenting on his post as if it were valid to the discussion is itself trolling.

      --
      Wheel in the sky keeps on turnin'.
  2. Re:rule number 1 by Anonymous Coward · · Score: 0

    None of those images even fazed me. Go back to /b

  3. It's not what you know ... by Anonymous Coward · · Score: 5, Insightful

    It's not what you know, it's who you know. That advice is contained in the article in spades. You are much better off being part of a community. When you find yourself unemployed, your next job will be determined by your reputation. The article points out that the best way to build a reputation is to contribute to open source projects. Slaving away in the back room on proprietary projects is a crummy way to build your reputation.

    On the other hand, the best way to make a lot of money has, up to now, been to know the right proprietary software. There was a time, not so long ago, when knowing Oracle would make the difference between making $30k or making $100k. I have a relative who made a lot of money because he was an expert in MUMPS. I think that is changing. Open source is the future. The article points out that jobs no longer last thirty years. You will probably work for many companies and your ability to get the next job is much enhanced if you are well known and respected in the community. The paradigm is changing and the old rules may not work much longer. In that respect I think the article has it exactly right.

    1. Re:It's not what you know ... by drsmithy · · Score: 4, Insightful

      On the other hand, the best way to make a lot of money has, up to now, been to know the right proprietary software. There was a time, not so long ago, when knowing Oracle would make the difference between making $30k or making $100k. I have a relative who made a lot of money because he was an expert in MUMPS. I think that is changing. Open source is the future.

      Open Source will not change this. Despite what seems to be common belief among some people, a program being open source does not make it a commodity. Non-trivial environments do not change software platforms on a whim, be they proprietry or open source.

    2. Re:It's not what you know ... by Anonymous+Brave+Guy · · Score: 3, Insightful

      I'm sorry, but I think you're overestimating the relevance of the OSS community.

      To give an obvious example, my employer is currently recruiting. The senior technical guys doing the interviews/selection know plenty about Linux and GCC, since we use them all the time. However, I doubt they've heard of anyone in the OSS community apart from maybe Linus and RMS. IME software development is a small world, and unless you're looking for your first or second job, it's far more likely that someone at a prospective employer will have worked with you before or know someone who did than that they will have read the credits of some piece of OSS you contributed to, remembered that your name was 17th on the list, and actively pursued you.

      This isn't to knock the value of contributing to OSS. Doing so can help you learn a lot, demonstrates a willingness to volunteer your time to something you think is worthwhile, and often shows that you can get things done as part of a large, distributed team. These are all good news for a prospective employer, so go ahead and put the work on your CV. Just don't have any illusions about headhunters coming knocking at your door because you once fixed a bug in $OBSCURE_OSS_TOOL. It just isn't going to happen, except for a very lucky few.

      --
      If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
    3. Re:It's not what you know ... by HazMathew · · Score: 1

      I disagree. The "It's not what you know it's who you know" slogan is really getting old. Let's be honest. The only people still using that phrase are retired old fogies that spent their lives working for the man. It lost it's "wise words" factor in 1973. In this day you have you know what you're doing as well as build working relationships and a professional network. The jobs I have gotten have always been determined by my skillset and experience and not my reputation with any open source projects, or even my past employers. Of course a good reputation never hurts. I doubt my employers even checked the references I gave them. The difference between $30k and $100k is experience and negotiation.

    4. Re:It's not what you know ... by qwijibo · · Score: 3, Informative

      Who you know still has a significant impact. Given two people who look on paper like they have equivalent experience, will you choose the one you've worked well with in the past, or try the unknown guy and see how it goes? Direct experience or internal references go a long ways in getting jobs. It's not a replacement for being able to do the job, but something that sets you apart among dozens or hundreds of people with comparable skills going after the same job.

    5. Re:It's not what you know ... by Cyberax · · Score: 1

      For example, my friend is the author of AntiGrain (http://antigrain.com/) library. He also works as a contractor (he's also typography specialist) and he says that a lot of his clients ask if he's the same guy who wrote AntiGrain.

      So I guess, OSS is a good for your own PR.

    6. Re:It's not what you know ... by RoloDMonkey · · Score: 1

      I have to disagree. Active participation in an open source project can get you work. If you reply to questions in the forums, edit the wiki, or contribute source code, people will notice. A user may offer you a bounty to do something they can't. Many of the forums have pages for posting services and jobs. If the project has a foundation or offers commercial services you may be asked to join.

      You are right that headhunters probably aren't reading documentation looking for names, but if they are asked to find someone who is good with OpenSourceProjectX, and they know what they are doing, they will probably go to opensourceprojectx.com and ask there.

      --
      Long live the Speaker Bracelet
      Rolo D. Monkey
    7. Re:It's not what you know ... by Anonymous+Brave+Guy · · Score: 1

      I'm not saying OSS participation can't get you work. Obviously it could, for example in the circumstances you suggest. I'm just challenging the rather dramatic statements in the post I originally I replied to (e.g., "Open source is the future") that seem to be saying that the traditional ways of getting highly-paid work in software development will just disappear in favour of those with reputations for contributing to OSS. I have seen no evidence that this is the case nor likely to be so any time soon, and I can't imagine why we should expect it to be.

      --
      If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
    8. Re:It's not what you know ... by Anonymous Coward · · Score: 0

      I'm well-known and respected in the FOSS community, and it amounts to precisely DICK in the job market. DICK. "Oh, so you spent years working on a project nobody gives a shit about. Great. How are you with C# on Windows Vista?"

    9. Re:It's not what you know ... by Doctor+Memory · · Score: 1

      The "It's not what you know it's who you know" slogan is really getting old. Uh huh. But "working for the man" is hip and fresh? And then there's the term "old fogies"...

      Seriously, I've gotten lots of work because I've been recommended by either clients or coworkers. I've also gotten lots of work because I had the right skills (or at least buzzwords) listed on my resume. Neither one is exclusive of the other, and you need both. If you've got an in-demand skill, then you'll probably find it fairly easy to move from position to position. However, if demand for that skill wanes (or the supply comes up sharply), then you're going to have to have some other way to distinguish yourself. That's where having a recognized name comes in. It's also good to have if you like to keep up with current technologies. Somebody starting a new SOA project may not have any idea how to evaluate someone's SOA knowledge level, but if they see your resume and remember you did good work on the $XYZ project, then they're much more likely to call you rather than somebody else who has XML, XSLT and Web Services listed as part of their skills.

      And don't forget, it's about soft skills too. Anybody can say "I work weekends if the project gets behind", but if a manager remembers getting a status report from you at 3AM on Monday, that's proof. Of course, they'll also remember if they came in on Saturday and found you deathmatching or using the project's copy of DreamWeaver to redo your band's web site, so it cuts both ways...
      --
      Just junk food for thought...
  4. The first advice is also the most important one by Opportunist · · Score: 5, Insightful

    Coding is a bit like sex. It's only satisfying when you do it for the joy of creating code, not if money's all that matters to you.

    I've seen a fair lot of people who're trying to get into the biz (the key word here is trying) for the money. This was especially a disease during the dot.com times. People who didn't have any love for the art of creating code tried to squeeze into the biz because "That's where the big bucks are". They would have shoveled shit if that would've been the next gold mine.

    That's not how it works. Writing code is painful at times when you love it, I can't even imagine what kind of hell it must be like if you don't like it in the first place. And when you don't do it out of love for the art, the product is going to be a living hell for those that have to suffer using it.

    But there's another advice I'd give to aspiring programmers: Learn your math, learn your algos. When you know how to solve a problem, language is not an issue anymore. When you know how something is done efficiently, it doesn't matter at all what environment you get pushed into, it doesn't matter if someone comes up with the next generation of code creation tools, you will grow into it smoothly. If you only know how to hack together code, copy/paste style, if that's how you implement your algorithms, you will have to relearn it again and again every time the environment and coding style changes.

    --
    We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
    1. Re:The first advice is also the most important one by cperciva · · Score: 5, Funny

      Coding is a bit like sex. It's only satisfying when you do it for the joy of creating code, not if money's all that matters to you.

      Also, it's very easy to make a mistake which you don't discover until several months later, but which you end up having to support for the next two decades.

    2. Re:The first advice is also the most important one by Opportunist · · Score: 3, Funny

      That only happens to novices who don't know how to do it in protected mode.

      --
      We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
    3. Re:The first advice is also the most important one by JNighthawk · · Score: 2, Insightful

      Very well put. I'd also add onto that two more points: experience is extremely valuable and don't re-invent the wheel.

      Experience helps a lot, since a problem is much easier to deal with when you've already seen something like it before. It's not everything, but the best way to become a better coder is, unsurprisingly, to code. Reading books is great, and definitely should be done, but you need to actually apply what you've learned.

      If you run into a problem and think "someone else must have had this problem before," you're probably right. Look around for solutions to common problems before trying to solve them yourself... after you've already solved it once. Gaining the experience is more important than saving time, but once you've learned how to do it, there's no reason to keep re-solving the same problem.

      --
      Wheel in the sky keeps on turnin'.
    4. Re:The first advice is also the most important one by seven+of+five · · Score: 3, Funny

      COBOL is a bit like sex.

      a missing period can mean big trouble.

    5. Re:The first advice is also the most important one by acroyear · · Score: 2, Funny

      But I *like* writing linked lists...

      --
      "But remember, most lynch mobs aren't this nice." (H.Simpson)
      -- Joe
    6. Re:The first advice is also the most important one by drix · · Score: 2, Funny

      Coding is a bit like sex. Wow.. I mean, have you had sex? Coz I just got finished doing both, and ... no.
      --

      I think there is a world market for maybe five personal web logs.
    7. Re:The first advice is also the most important one by raddan · · Score: 1

      When you know how something is done efficiently, it doesn't matter at all what environment you get pushed into, it doesn't matter if someone comes up with the next generation of code creation tools, you will grow into it smoothly. This is true. I reached awhile ago, when which programming language I used didn't matter so much anymore. Nearly all modern languages offer the same features, and syntax is something you must get through, but once you know how to frame a problem in your mind, the solution usually just falls out. When a language is unfamiliar to me, pseudocode is very useful in this regard, until I can straighten out how to write the program in the new environment. I even find myself writing pseudocode for decisions I need to make in my everyday life-- it's a great way of abstracting a problem.

      Anyhow, back to programming language not mattering-- I am not a proficient speaker of foreign languages (me "speaking French" is like a script kiddie "writing code"), but I do wonder if multi-lingual people, for whom languages come easy, think of it the same way.
    8. Re:The first advice is also the most important one by JNighthawk · · Score: 1

      Get hired as Linked List Programmer :-P

      --
      Wheel in the sky keeps on turnin'.
    9. Re:The first advice is also the most important one by kalirion · · Score: 1

      But there's another advice I'd give to aspiring programmers: Learn your math, learn your algos.

      Don't forget to learn object oriented design, patterns, refactoring and all that. All the math and algorithms in the world can become useless if your code is an unmaintainable mess.

    10. Re:The first advice is also the most important one by qwijibo · · Score: 1

      Let me guess, your coding involved maintaining someone else's Perl code? That's not pure coding for the enjoyment of coding. That's more like being forcibly raped.

    11. Re:The first advice is also the most important one by Opportunist · · Score: 1

      Actually it is.

      I've had the worst time learning French at school, simply because I tried to learn the language, learning vocabulary by heart and grammatics rules, all the junk.

      Then I started to get interested in language theory and development, learned a bit of the history of western European languages, and over time I started to 'understand' a few words in foreign languages even though I never learned them. I don't speak Italian or Spanish, but, if spoken slowly (or written), I can puzzle together at least what it's about. It's not really hard at all.

      It's the same as in pretty much every field. If you understand the underlying theory, converting it into practical applications is usually easy. If you only have "hands-on" experience, you can deal with the problems you know, but you can't generate new solutions to problems you never encountered.

      --
      We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
    12. Re:The first advice is also the most important one by Opportunist · · Score: 2, Insightful

      Object orientation is more a principle of organizing code, imo. Not so much a way of coding itself.

      For me, OO is the "container" for my algos. And I'm pretty sure that someone will come along sooner or later and create the better container, organize it differently. It could change from the very foundation, just like OO changed coding styles from grounds up when it came along.

      Math will always stay the same. The basic principles won't change.

      --
      We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
    13. Re:The first advice is also the most important one by sheetsda · · Score: 1

      Speaking of protected, in college one day a professor wrote some C++ code on the board, and he forgot the 'L' in "public", and so declared a class with a "pubic" area. Somehow I was the only one who noticed this (or the only one with a juvenile sense of humor). The prof must have thought I was crazy by the end of the class with me sitting there trying to contain my laughter to see how long it would take anyone else notice. They never did.

    14. Re:The first advice is also the most important one by Bluesman · · Score: 3, Insightful

      Don't worry -- if you keep having sex, it will get better.

      --
      If moderation could change anything, it would be illegal.
    15. Re:The first advice is also the most important one by ASkGNet · · Score: 1

      In C++, your friends can touch your privates
      However, your father's friends can't.

    16. Re:The first advice is also the most important one by Workaphobia · · Score: 1

      That one is always flying around the CS2 class I TA, but only the first line. I'll have to recommend the second to them.

      There's also the simple gag about using a little something to avoid getting littered with stds.

      --
      Evidently, the key to understanding recursion is to begin by understanding recursion. The rest is easy.
    17. Re:The first advice is also the most important one by Opportunist · · Score: 1

      You say that like it should be different. Is there something we should know? :)

      --
      We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
    18. Re:The first advice is also the most important one by Opportunist · · Score: 1

      Well, in both cases it depends on how you do it and with whom. With time your demands rise in both areas, and when you've seen and done a lot, the more trivial things don't tickle your nerves anymore.

      Though it's way easier to convince your compiler to crunch through a piece of code that does synchronized double remote threading than your girlfriend that it would be neat to have her best friend in bed, too. At least your compiler won't decide to uninstall as a result.

      --
      We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
    19. Re:The first advice is also the most important one by barzok · · Score: 1

      Writing code is painful at times when you love it, I can't even imagine what kind of hell it must be like if you don't like it in the first place. And when you don't do it out of love for the art, the product is going to be a living hell for those that have to suffer using it.
      Ever worked with someone who doesn't like it in the first place? That's a whole other level of hell. Forget that person's bad feelings, the product, and the users - it drains the other people on the team who do enjoy the work even more. And that just ruins the whole project and product.

      I once worked with a "programmer" who told me that if it weren't for the on-call portion of her job requiring the ability to work from home, she wouldn't even own a computer. And it's not like she was fresh out of college looking to cash in during the dot-com days - she'd been with the company at least 15 years at this point and was considered a "senior" developer.

      I was in the midst of explaining a 20-line DOS batch file (which just did some file copies and called a couple other scripts) to her when she told me this. I died just a little bit more inside on that day.
    20. Re:The first advice is also the most important one by Opportunist · · Score: 1

      Sure did. I enjoyed it lots, we had someone who WANTED to go to the meetings.

      I wouldn't want to work without such a person in my team. You just have to assign them the right job. Our anticoder was the one to send to meetings and pointless demonstrations, he loved every moment of it and felt useful for the first time. We on the other hand didn't have to deal with tie-wearing cluebricks and waste our time playing bullshit bingo in meetings.

      I love win-win situations.

      --
      We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
  5. A hard reality... by ranga_the_don · · Score: 1, Insightful
    When the author says,

    The network really is the computer There are now no interesting non-networked applications. Standalone computers are devices for watching stored video or listening to music, usually on airplanes.
    I agree completely since it is a fact that has been established over the years, i still wonder if iTunes(one of the best examples i could remember) would have been so widely used today if not for the music sharing feature!
    --
    - Yes, but does it run Lunix?
    1. Re:A hard reality... by drsmithy · · Score: 4, Informative

      I agree completely since it is a fact that has been established over the years, [...]

      I have to argue there are still a lot of computing applications where the network is of only tangential interest. Word processing, desktop publishing, video editing, [single player] games, etc. There's no shortage of work where the network is really just a a process for getting an initial set of data onto the machine to be manipulated (if it even does that - eg: photo editing with photos coming straight off the camera).

      Mr Allison's advice (and commentary) seems to be very much centred around writing high-performance server applications. Which is hardly surprising, given his background, but may not be equally applicable to all forms of coding (eg: writing GUI apps for GNOME or KDE today is probably quite different to writing X apps twenty+ years ago, and an intimate knowledge of the underlying hardware/OS is only really necessary if your code is performance-sensitive).

      [...] i still wonder if iTunes(one of the best examples i could remember) would have been so widely used today if not for the music sharing feature!

      Of course it would. The iPod is the main reason iTunes is popular (( don't think I've _ever_ used iTunes music sharing features - or the iTunes Store, for that matter).

    2. Re:A hard reality... by ranga_the_don · · Score: 1, Informative

      I have to argue there are still a lot of computing applications where the network is of only tangential interest. Word processing, desktop publishing
      Office automation is moving out of the standard Desktop application paradigm to online browser based rich clients with the rapid growth and advancements of Web 2.0 a.k.a AJAX, XHTML and allies. The paradigm shift to virtual offices has already begun!

      There's no shortage of work where the network is really just a a process for getting an initial set of data onto the machine to be manipulated (if it even does that - eg: photo editing with photos coming straight off the camera). I wonder why Major Camera manufacturers have started building cameras with wi-fi support then...

      The iPod is the main reason iTunes is popular (( don't think I've _ever_ used iTunes music sharing features - or the iTunes Store, for that matter).
      I don't agree here, initially people might have started using iTunes only since the time they got acquainted with an iPod, but that's not the case anymore... It is a must that you need iTunes if you have an iPod, but the reverse is not at all true. Podcasting is a runaway hit with web savvy population, and i don't think you would need an iPod to listen to podcasts And your code is definitely performance sensitive if you are not giving it out for free and selling it as a Product or a Service...
      --
      - Yes, but does it run Lunix?
    3. Re:A hard reality... by demallien2 · · Score: 2, Insightful

      "Mr Allison's advice (and commentary) seems to be very much centred around writing high-performance server applications. Which is hardly surprising, given his background, but may not be equally applicable to all forms of coding (eg: writing GUI apps for GNOME or KDE today is probably quite different to writing X apps twenty+ years ago, and an intimate knowledge of the underlying hardware/OS is only really necessary if your code is performance-sensitive)."

      So not true. A simple example. You're writing a video editting program that needs access to the graphics card. Sadly your code and the card's driver aren't playing nice together. You've read the docs, you think you're doing the right thing, no-one on the forums can give you any pointers. What do you do? Ideally, you'd have a look at the source code of the driver - the ultimate documentation, to see what the driver is expecting of you. Trouble is, you're coding against an NVidia graphics card, and the bastards don't give out the source code.

      Well, I for one would flick on the debugger, and reverse engineer the driver, see what it's doing... Bit hard to do if you don't understand how the OS driver model is set up, or if you don't understand your processor's assembly language, or how compilers generate stack frames, manage memory access bla bla bla.

      This is not some pie-in-the-sky, never happens kind of scenario. I work in an embedded environment. My company produces a library which requires that our partners implement an interface. Trouble is, when we try to integrate our code and their code, it doesn't work. I don't know how many times I've sat in meetings with colleagues and the client where the two sides argue over where the bug is. Happily for me, I don't ever have to do that. I simply tell the client where the bug is in their code, because I've reverse-engineered it, and identified the problem, to the point where I can often tell them things like "you're not incrementing the pointer in the second case of the switch statement". End of argument, and the bug is corrected within hours if not minutes. The only other option is black-box testing to identify what the client is doing wrong, and even then you can only tell them in general terms.

      Yet another example. I have loads of colleagues that know how to write some html/javascript, and put it up on a web server. But when for whatever reason they can't create a correct session between their client device and the server, they are completely lost. No idea how routing works. No idea how NATs work. No idea how to use a packet sniffer to see whether the TCP connection is correctly established. In other words, no idea how to debug the system.

      There is no coding job in the world where an understanding of the underlying architecture won't enable you to be more effective. You're code will be smaller, faster, you'll have more tools available when trying to debug a system, or doing integration. You'll even be able to copy algorithms that you only have in binary form.

    4. Re:A hard reality... by Anonymous Coward · · Score: 0

      but as a young programmer looking at the future I see word processing and other historically solitary computer tasks as soon to be relics, so the advice is decent. probably not so much for programmers at the end of their careers.

      i will always want to play with hardware, but look forward to the day when all i need is a cell-phone, wireless headset & a networked printer to perform all of my business related tasks. i can keep a laptop on hand in case of transcription errors in the product that my online transcription service sends to my printer... etc...

      the network is the computer, I am an input device.

    5. Re:A hard reality... by drsmithy · · Score: 1

      So not true. A simple example. You're writing a video editting program that needs access to the graphics card. Sadly your code and the card's driver aren't playing nice together. You've read the docs, you think you're doing the right thing, no-one on the forums can give you any pointers. What do you do? Ideally, you'd have a look at the source code of the driver - the ultimate documentation, to see what the driver is expecting of you. Trouble is, you're coding against an NVidia graphics card, and the bastards don't give out the source code.

      1. Video editing. That's performance-sensitive code, so you don't even get off the mark ok.
      2. You shouldn't be talking to the hardware, you should be talking to the system API.
      3. You should be writing to the documented API, not delving inside the source code and reverse-engineering how you think it works. Doing so is very, very bad practice and will likely result in fragile code tied to a specific implementation of the API (shennanigans like this are the primary reason software updates in Windows sometimes break applications).

      This is not some pie-in-the-sky, never happens kind of scenario. I work in an embedded environment.

      Well, duh. At no point did I say there was no reason for any developers to know about the hardware. Why are you trying to pretend I did ?

      The only other option is black-box testing to identify what the client is doing wrong, and even then you can only tell them in general terms.

      No, the other - proper - option is to tell them their API isn't acting the way their documentation says it does. Not to fix their problem. Not to write your code to work around their problem (so that it breaks when they subsequently fix it).

      There is no coding job in the world where an understanding of the underlying architecture won't enable you to be more effective.

      Something I haven't disagreed with. It is, however, far from _necessary_ for a non-trivial amount of coding work out there. Someone writing a low-usage web app doesn't need to know assembler.

    6. Re:A hard reality... by demallien2 · · Score: 1

      You weren't really paying attention there were you? Point 2 for example. My whole point is that the documented API is not working the way that you expected. Bad docs? Bad code? Who cares, it's not working. Your approach apparently is to throw your hands in the air, and go and sulk in the corner. Someone that can reverse engineer the driver will be able to continue going forward.

      Point 3. Again, the documented API isn't working. Is it a bug in your code, or a bug in their code? Only a reverse engineering session will give you the answer. If it's a bug in your code, you will know what's going wrong, and you'll be able to fix it quickly. If it's a bug in their code, you'll be able to produce a detailed bug report, which is much more likely to be addressed than some vaguely described symptoms.

      "Something I haven't disagreed with. It is, however, far from _necessary_ for a non-trivial amount of coding work out there. Someone writing a low-usage web app doesn't need to know assembler.".

      And I never said that someone that doesn't know the underlying architecture can't hack together something simple. If that's what you consider programming, well - you probably aren't producing very good code. Anyone that wants to be a good programmer needs to know about the underlying architecture. At least, that's Jeremy Allison's position, which I happen to share. But apparently you think you know more about what a good programmer needs to know than Jeremy

    7. Re:A hard reality... by Mycroft_514 · · Score: 1

      And you are right, there are plenty of stand alone aps even now. And plenty of network ones.

      Some examples of stand alone turn around secondary devices. Dive computers, blood meters, blood pressure meters. You don't need the network for these.

      Listening to MP3 files. Yes, I use a network ap to download them, but I listen to them in standalone mode.

      Photoshop. Yeah, Adobe is making noise about a web centric version of Photoshop. I'll believe it when Cows fly. There just isn't enough bandwidth yet to do that kind of processing in a timely manner.

      Word Processing? Why in the h.ll would I want to go to a browser model for that? Talk about stupid.

      The Laptop is the coming wave - look at the sales figures. And what does a laptop do? Connects to get data, then walks away from the network.

      Also, I will give the original author credit about needing to know what is going on underneath, but he forgot a BIG piece of that puzzle. You need to know what your DBMS is doing under the covers. A few years ago I ran into one spot where if you followed the natual inclination and went forward thru the answer set you ended up with a factorial I/O issue. If you went backwards, it was linear. Not a problem when testing for 5-10 rows, but try going to production with hundreds and thousands of rows....

    8. Re:A hard reality... by benj_e · · Score: 1

      Sorry, but I can't fully agree with this. When I started out in programming, it was on the System/38, a system specifically designed so that you didn't have to know the architecture. In fact, the entire underlying hardware architecture could change and you wouldn't (normally) have to recompile any code since the microcode handled all that.

      --
      The Tao that can be spoken is not the one eternal Tao
    9. Re:A hard reality... by drsmithy · · Score: 1

      You weren't really paying attention there were you? Point 2 for example. My whole point is that the documented API is not working the way that you expected. Bad docs? Bad code? Who cares, it's not working. Your approach apparently is to throw your hands in the air, and go and sulk in the corner. Someone that can reverse engineer the driver will be able to continue going forward.

      Sure, with some bad code that will likely break every time the other vendor changes anything.

      It's crap like this that causes 90% of the problems on Windows. Developers write their code to some "reverse engineered" spec of the API, rather than the documented one, so then when the API's implementation changes in some minor way, all those badly written applications brreak. Microsoft subsequently has to write in layer after layer of "bug compatibility" so old applications don't break.

      Anyone that wants to be a good programmer needs to know about the underlying architecture. At least, that's Jeremy Allison's position, which I happen to share. But apparently you think you know more about what a good programmer needs to know than Jeremy

      No, I said I can see why people trying to write high performance network servers and other such performance sensitive code - clearly the type of developers Mr Allison's remarks are most relevant to - will benefit from knowing the underlying architecture.

      However, that's not the majority of code out there being written. For most developers, knowing the architecture is handy, but far, far from essential.

  6. Eh? by Anonymous Coward · · Score: 0, Insightful

    Grandparent "On the other hand, the best way to make a lot of money has, up to now, been to know the right proprietary software."

    Parent "Open Source will not change this."

    So you're saying that the best way to make a lot of money is to know the right proprietary software? Probably not. In any event, you're not even wrong.

    1. Re:Eh? by xENoLocO · · Score: 2, Insightful

      He *is* correct, ya know... do a search for COBOL jobs now that all the COBOL guys are retiring, and check out the salaries involved.

      --
      "The need to build the internet comes from something inside us, something programmed... something we can't resist."
    2. Re:Eh? by BadERA · · Score: 1

      I saw a listing for a COBOL programmer for $17-$23/hour the other day ... sorry to shoot your post down ...

      Now, in late 99, sure, their salaries were high ...

      We have a number of COBOL consultants here where I work, and the company only offers them $65k or so to go permanent -- one guy makes about 110 or so contracting, and they offered him 65. We have a number of permanent COBOL programmers in place, and I don't think they're making much more than that either. On the .NET side, people making 90-100k are getting offered in the low to mid 80s ...

      --
      I am, therefore you think.
  7. And of course, by HarryCaul · · Score: 3, Funny


    Wear Sunscreen.

    1. Re:And of course, by Anonymous+Brave+Guy · · Score: 2, Informative

      For those a little too young to get that, here's the original. And yes, it's definitely worth reading. :-)

      --
      If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
  8. Excellent Advice by Aging_Newbie · · Score: 3, Insightful

    I wouldn't change a thing in what he said, and that is saying something! I put it right up there with The Tao of Programming as a worthwhile resource for new programmers.

    1. Re:Excellent Advice by kestasjk · · Score: 2, Insightful

      I disagree, it seems to have been completely written from the perspective of the code he writes.

      Don't tell me that POSIX is a more valuable (speaking in terms of money) thing for a programmer to know than the latest thing out of Microsoft. If you call things that change a "trap" then POSIX is one of the very few things which hasn't been a trap (including Java, which Allison praises).

      He talks about machine code still being very relevant, and that you can't write code for thousands of machines working in a cluster without it. Well, most people don't write code for thousands of machines working in a cluster.
      I agree machine code is good to know, but not for the reasons he gives.

      It's interesting to hear his take, but I think Allison is a bit removed from the average developer in terms of the sorts of things that he has developed.

      --
      // MD_Update(&m,buf,j);
    2. Re:Excellent Advice by Aging_Newbie · · Score: 5, Interesting

      In strict fairness I have to agree with your Microsoft comment; however, I come down on the side of not chasing the money but chasing, instead, the love of programming and the heady pleasure of making something really complex and significant work.

      In more than 16 years of doing MS programming and chasing the latest thing to keep ahead, I look back and wonder how many projects might still be in use if they were in Linux/Unix. Instead, the products died with their native OS. Further, once on the MS money train, the only alternative is to chase the newest thing to keep in place or move slightly ahead. In addition, I have seen many other proprietary toolsets come and go. In fact, some of the toolsets were simply created, it would seem, to capture customers who would need programmers for those toolsets in order to maintain the code. Then, finally, when the product is stable, it is time to migrate it to the new version at even greater cost. Lock-in is great, and only now do businesses recognize the risks it brings.

      As for machine code, I agree that not too many need to master it. I have done my share of assembler in lots of environments and believe strongly in the importance of wrapping one's head around what is really happening. If you notice, buffer overflows are the most exploited weakness of modern applications. Once you debug a buffer overflow in assembler code, you remember full well how important it is to avoid them. On the other hand, if somebody really understands what is happening in the machine and OS then C and C++ are very efficient ways to program. And, Java, which keeps the executing machine relatively constant, is maybe the grail of programming. Even then, understanding what the virtual machine is doing with that Java statement is important in making efficient code.

      I also agree he is somewhat removed from the majority of developers. But, the majority of developers are probably focused on the other aspects of development. That topic is best handled by this excerpt from "The Zen of Programming"

      -----
      There was once a programmer who was attached to the court of the warlord of Wu. The warlord asked the programmer: "Which is easier to design: an accounting package or an operating system?"

      "An operating system," replied the programmer.
      The warlord uttered an exclamation of disbelief.
      "Surely an accounting package is trivial next to the complexity of an operating system," he said.
      "Not so," said the programmer. "When designing an accounting package, the programmer operates as a mediator between people having different ideas: how it must operate, how its reports must appear, and how it must conform to tax laws. By contrast, an operating system is not limited by outward appearances. When designing an operating system, the programmer seeks the simplest harmony between machine and ideas. That is why an operating system is easier to design."
      The warlord of Wu nodded and smiled. "That is all good and well," he said, "but which is easier to debug?"

      The programmer made no reply.
      -----

      So, there you have it. The majority of developers create applications that require focus on the externals and present their own difficulties and challenges. Those challenges are not so much technical as people and business. The two challenges meet, though when the accounting package is killed by a proprietary product migration, and has to be redone (if there is money to redo it).

      In truth, I find it hard to counsel new programmers because the world is changing so quickly. Having been burned repeatedly with proprietary lock-in and migrations, businesses now buy their applications from major vendors and change their processes and practicies to comply with the constraints of the software. I personally think that the resulting uniformity in methods will eventually stagnate the companies who do this. But, when you consider that corporations can only see a quarterly horizon, maybe that is the best that can be expected.

    3. Re:Excellent Advice by aadvancedGIR · · Score: 1

      I never touched POSIX, Java or any web or network thing, but rely heavily on machine code and C, does that mean I'm not a developer, or simply that my job is to code drivers on embeded devices?

    4. Re:Excellent Advice by Aging_Newbie · · Score: 1

      You are most certainly a programmer and probably a very good one!

      The buffer overflow I mentioned was in a Motorola 6801 before I started chasing the MS rainbow.

    5. Re:Excellent Advice by 0xABADC0DA · · Score: 4, Interesting

      In more than 16 years of doing MS programming and chasing the latest thing to keep ahead, I look back and wonder how many projects might still be in use if they were in Linux/Unix. I still get email occasionally from people who dig up some little program I wrote for unix 12 years ago. Sometimes they find it from USENET, sometimes just floating around the net someplace, and then they go to the trouble of searching the net to find my current contact just to say 'thanks' or to let me know that it works on whatever linux distro on amd64. The systems they were written for are now long-dead.

      The Unix standards are just better than many others. They are simpler and more elegant, and they last a long time. On a cross-platform project I was working on recently some windows developer changed "uint32_t" to a "typedef DWORD UINT32_T" and "typedef uint32_t UINT32_T". Wtf is a DWORD and why not typedef it to uint32_t. I believe doing too much Windows programming warps even the best programmers; you either move on to something else or you lose the ability to write good code.
    6. Re:Excellent Advice by rekil · · Score: 1

      All the modern layers of 'glop' are designed to provide increased levels of abstraction making it quicker to develop applications. The real value in learning low level languages hinges on the realisation that any subsequent layers added on can't do anything outside the physical scope of the very finite set of instructions available. Once programmers get a handle on low level basics, it's a trivial matter switching between high level programming languages, it's all just variables, objects, arrays, lists &c. anyway. It would take a fairly lengthy amount of time to learn PHP and then try and apply your knowledge to COBOL if you weren't aware that basically (at some level of abstraction) all programming languages are the same and all you need do is familiarise yourself with the syntactical differences. So, yup, machine code is very relevant but not for the reasons he states.

    7. Re:Excellent Advice by Anonymous Coward · · Score: 0

      Wtf is a DWORD
      how the hell did this get modded +5?
    8. Re:Excellent Advice by Anonymous Coward · · Score: 0

      because most mods understand that sarcasm of saying 'wtf is a DWORD?'. uint32_t is a type for unsigned integers with 32 bits.

      DWORD is a Double WORD. Except it isn't, it's a word (on i386) and a half-word (ia64) and only a double word on 8088 style 16-bit intel chips.

      So you now see the point of unix standards being simpler and aging better... ?

  9. What about us old folk? by Cragen · · Score: 1
    Seriously, there's a lot of us who are in our late 40's and 50's (some of us with kids in high school, college, etc.) who are getting a little jaded at learning a new "paradig-im" every 2-4 years, but still gotta tough it out to keep those DNA-packets in the human network of higher learning, etc. It would be good to hear serious advice about ways to keep the ole brain-fires stoked or, at least, ways to get yet another leg up on the new stuff, which we won't use at work for X years and which we don't have time to learn in our off-time. (Waa-Waa..) Do you think companies would fall for ^h^h^h^h^h^h^h^h think it's a good idea to pay an experienced web-app designer a little less so he could learn the new language (.Net, .Whatever, etc.) and the new environment? Sitting' tight here in paradise, but things usually change, when you least expect it.

    Cragen

    1. Re:What about us old folk? by littlewink · · Score: 1

      Sorry, bad news. At that age, you're in the crosshairs if you're in the private economy.

      If you can afford to retire then start taking evening courses in something you're interested in and that is a growth industry, say, bioinformatics.

      If you can't afford to retire, then start taking evening courses in paramedicine or nursing, so that when you're fired you can quickly get a job.

      Consider working for the local city, county or state government. Those jobs are very steady, hours are good, they discriminate less against older workers and they usually have good benefits and retirement plans. Don't expect the salary to match private industry.

      Start networking. And talk to others who have retired/left before you and see what they're experiencing in the local job market.

  10. curiosity saved the cat by ackdesha · · Score: 1

    TFA is dead on. My advice is to work daily on your curiosity and creativity skills. Don't tell yourself you are better or the best. It isn't about that. Learn to be a good user and administrator of software, so you can walk in others' shoes (apt-get is your friend for this). test test test. When your emotions get the best of you this may help (it helps me): http://en.wikipedia.org/wiki/Noble_Eightfold_Path.

  11. Here's the best piece of advice I could give by hey! · · Score: 5, Insightful

    Have convictions and be prepared to defend them. The worst mistakes I've ever seen have been by people doing things they knew they ought not be doing and hoping that lack will keep them out of trouble.

    I know this sounds like ridiculous advice to give to young people, who for perfectly understandable reasons tend to have more convictions than they have experience. But that changes all too rapidly, and the time will come when you will need your integrity muscles, and you don't want to find out they've gone flabby on you.

    It is the job of the engineer to do the things that are too hard for most ordinary people to do: analyzing, calculating, planning and designing. Courage and integrity are a vital parts of the engineer's role. Integrity is simply this: fitting your deeds to your words, or in an engineering context, delivering what you promise. Much of business runs on denial; on promises made with no actual knowledge of whether they are possible to fulfill. As an engineer denial has to stop with you. It's your job to deal with things as they actually are, not as we wish them to be. This means sometimes you have to make the unlikely probable, or to deliver at least something of value when confronted with the impossible.

    An easy way to have integrity is to play it safe. There is nothing wrong with playing it safe; its the best choice most of the time. But sometimes the reality is that the apparently safe course spells failure. From what I have seen, young engineers tend to either play it safe all the time or to take unnecessary risks. Aristotle said that courage is not the opposite of cowardice; it is the midpoint between cowardice and rashness. Every worthwhile project has an element of risk, but as an engineer it behooves you that this be a calculated risk. Leave the wishful thinking to others who don't have reality based professions.

    In engineering, every interesting problem involves dealing with pairs of desirable things, of which you can't have both in unlimited quantities. An aircraft ought to be as light as possible and as strong as possible, but the lightest possible aircraft is not strong and the strongest possible aircraft is not light. An engineer ought to have integrity, but be flexible in his approach. He ought to have convictions, but work smoothly and professionally with others. He needs honesty, but also discretion about when and to whom the truth must be told.

    All of which is damn near impossible. But if it were easy, everybody could do it.

    --
    Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
    1. Re:Here's the best piece of advice I could give by HazMathew · · Score: 1

      I LOVE THIS JOB! HOORAH!

    2. Re:Here's the best piece of advice I could give by Moe1975 · · Score: 1

      A most excellent post - thank you.

      --
      SARAVA!
  12. "Do what you love" is overrated by MikeRT · · Score: 3, Insightful

    Doing what you love is all well and good, but if you have a family, you have a responsibility to support them. This swings both ways, it means that a man may have to do a job that he doesn't like, and a woman may have to give up a job she likes in order to be there for her kids. To do otherwise is not only irresponsible, but it leads to the sort of families that get denounced on every game thread here.

    Here's a better suggestion: find a job that is run by people who appreciate the fact that work is not the be all, end all thing in your life. You'll be a lot happier with an employer who asks you to only do 40 hours, unless there is an exigent circumstance.

    And here's another... if you spend 12 hours a day at work and in commute, chances are you won't have a great relationship with your significant other after several years. Your kids won't know you. You'll be happy, but chances are, that happiness will be at work, not at home.

    1. Re:"Do what you love" is overrated by hey! · · Score: 3, Insightful

      "Doing what you love" is like saying you should be in love with your wife 7x24, forever.

      Chances are one day you're going look over at your wife and realize she's old, fat and crabby. Maybe if you're rich you'll buy yourself a new, young, pretty wife who is docile as a lamb. But in the end you still won't be happy. And the people around you will justly despise you and your new wife. If you look in the mirror you'll see you're no prize yourself.

      The state of being in love, either with your spouse or with your job, is necessary to the continuance of civilization, but it is not sustainable.

      It would be better to say this: "love what you do." This better captures the effort and imagination needed to live a life of what the Greek philosophers called "Eudaimonia": a kind of sustainable well-being.

      Then in choosing a job, you should not choose that which you simply have a passive attraction to. You should choose something believe you have the capacity to generate new love for that will carry you through the hard times.

      --
      Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
    2. Re:"Do what you love" is overrated by Billly+Gates · · Score: 1

      Well if family is what you love then you do a job so you can support them more. If having a big house is what you love then you do not care about the job as much as the pay.

      Right now I am not finished with my degree and I want to do what I love programming but lack the degree now in this post .com crunch.

      My fiancee is letting me do what I love and get my degree while I only work part time. She works full time but she prefers me to be happy and spending time with me rather than me having 2 borderline slave jobs for a slightly bigger house.

      So do what you love and if your family has trouble with this then she or he is the wrong person for you.

    3. Re:"Do what you love" is overrated by xero314 · · Score: 2, Insightful

      The state of being in love, either with your spouse or with your job, is necessary to the continuance of civilization, but it is not sustainable. Sorry you feel that way. After more than 10 years of marriage in a 13 year relationship I am more in love today that ever before. I have also been programing for over 25 years and enjoy it as much to as I did day one. In both circumstances my interests have changed but the overall feeling has not. In the case of programming I have even gone full circle and am back to desiring work involving machine code or even hardware design, as opposed to the higher level rapid development I have been doing for years.

      If you are the kind of person who "falls" in and out of "love" I would suggest reconsidering what it is you love, since it's obviously not the person or the job, or question wether you even love at all.
    4. Re:"Do what you love" is overrated by Anonymous Coward · · Score: 0

      Besides, no one will pay me for being higher than a kite and having wild sex, so "do what you love" would result in starvation. Then again, after enough starvation, maybe I could get paid for it...

    5. Re:"Do what you love" is overrated by Javagator · · Score: 1

      xero314, there is more good advice in your post than in the entire Allison article.

    6. Re:"Do what you love" is overrated by xero314 · · Score: 1

      xero314, there is more good advice in your post than in the entire Allison article. Thanks, I only hope that it actually has the same effect on those that it might actually help and not just the people that already understand it.
    7. Re:"Do what you love" is overrated by Anonymous Coward · · Score: 0

      If not working is what you love, you won't find love in working.

  13. Reinventing the wheel == learning by Opportunist · · Score: 2, Insightful

    Generally, you're right. But the best a novice programmer can do is to reinvent the wheel. Over and over. Writing the billionth bubblesort surely will not add anything meaningful to the world's codebase, but it's a good way to improve yours.

    --
    We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
    1. Re:Reinventing the wheel == learning by RzUpAnmsCwrds · · Score: 1

      Writing the billionth bubblesort surely will not add anything meaningful to the world's codebase, but it's a good way to improve yours.


      Bubblesort is absolutely the opposite of what new programmers should be doing. The problem with today's powerful computers is that even a bad algorithm appears fast for a sufficently small data set. Unfortunately, this teaches programmers that "bad algorithms are OK" - when they try to sort a lot of items, or a few items many times, suddenly their code is horribly slow. What's their reaction? They try to "optimize" their code with hacks that are often counterproductive.

      New programmers need to understand how to use the resources they have been given. They should write a hashtable-based associative array, but they should also understand how to use the standard library.

      Students need to understand Big O notation and how different algorithms react to different input sizes. Understanding that insertion sort is often faster than mergesort or quicksort for very small data sets is just as important as understanding that it's inapproprate for large data sets. The problem with bubble sort is that it performs poorly relative to nearly any other algorithm for any data size - it is NEVER the best algorithm. Instead of implementing a bubble sort, students should learn how recursion works, then write a mergesort or radix sort - it's no more difficult to understand, and it's far more useful in the real world.

      Neither Computer Science nor Software Engineering are about writing code.
    2. Re:Reinventing the wheel == learning by JNighthawk · · Score: 1

      I, uh... said that. There's no point to continue re-writing the same things once you've learned them, though. No, writing bubble sort over and over will *not* help. It is a simple algorithm that cannot be optimized to the point of needing to write it more than a few times. There are few things that are sufficiently complex that have not already been solved where it would be worth it to continuously re-write it.

      --
      Wheel in the sky keeps on turnin'.
    3. Re:Reinventing the wheel == learning by sydneyfong · · Score: 1

      Given the poor performance of bubblesort over almost ANY data set, I don't think it would add anything meaningful to one's own personal codebase either.

      How about mergesort? Or a nice quicksort with good pivoting?

      --
      Don't quote me on this.
  14. 70% of jobs are not advertised by Anonymous Coward · · Score: 0

    http://www.careerowlresources.ca/articles/articles 04-26-02.htm

    Unless most career sites are wrong, most jobs aren't advertised. When I look back at my own career, a couple of my best job changes came because a friend said something like: "Why don't you come work over here." I certainly wouldn't be where I am without a little help from my friends.

    Your success on the job is determined by your people skills. There have been studies documenting that for the last sixty years.

    You can be the rugged individualist if you want but it will bite you in the ass sooner or later, if it hasn't already.

    1. Re:70% of jobs are not advertised by HazMathew · · Score: 1

      Since when does being an individualist imply poor communication skills?

  15. Community by Profane+MuthaFucka · · Score: 1

    I would have expanded the section on community being more important to include something about the importance of computer lore.

    You should learn about and know the stories which have been handed down from those who have gone before, because stories are a cornerstone of any community. If you've never heard of the programmer named "Mel" you should look him up. There's a whole pile of this.

    Do you know what a scratch monkey is? Knuth and his obsession with fonts? How much is a binary dollar and how could you earn one? Would you have cashed that check? The first computer bug was famous, but what else do you know about the discover of that bug? Do you TOP POST (don't do it, it shows a lack of respect for convention and tradition.) How about the Tao of Programming? Do you know when the summer that never ended began? Can you become famous with grep like Kibo did? When is the first time you ever heard of David Rhodes or a green card lawyer? The University of
    Texas has Dr. Dijkstra's papers online. Have you read them?http://www.cs.utexas.edu/users/EWD/ Do you know where the original Kremvax was located?

    Have you ever purposely thought about how you could create some community folklore of your own?

    If you don't give a crap about the folklore and history of the community you're thinking of becoming a part of, then that is one sign that maybe it's not for you.

    --
    Fascism trolls keeping me up every night. When I starts a preachin', he HITS ME WITH HIS REICH!
    1. Re:Community by Knara · · Score: 1

      Do you know when the summer that never ended began?

      I'm assuming that you mean "The September That Never Ended"

    2. Re:Community by Profane+MuthaFucka · · Score: 1

      Yes, that's it. Obviously you know your lore very well.

      --
      Fascism trolls keeping me up every night. When I starts a preachin', he HITS ME WITH HIS REICH!
  16. Maybe that works for him... by daveisfera · · Score: 2, Insightful

    I agree with the "do what you love" statement, but I can't say that I really agree with any of his "technical" points. Sticking to non-proprietary standards works really well in some cases (like web-based development), but in some cases non-proprietary standards just don't exist or really suck. Plus, the "network is the computer" thing works well for Google, but if you're writing a client only app or embedded code on a small device (which is still a huge part of the software industry, despite what many believe) then that just doesn't make sense.
    I agree with the general message of the article, but some of the points are too focused on the view from his limited perspective.

  17. amoral outsourcing by Anonymous Coward · · Score: 0

    I think the amoral outsourcing characterization is a bit unqualified given recent leading thought on the subject:

    Paul A. Samuelson, "Where Ricardo and Mill Rebut and Confirm Arguments of Mainstream Economists Supporting Globalization," Journal of Economic Perspectives 18(3), Summer 2004, pp. 135-46.

    Jagdish Bhagwati, Arvind Panagariya and T.N. Srinivasan, "The Muddles over Outsourcing," Journal of Economic Perspectives 18(4), Fall 2004, pp. 93-114.

    Alan S. Blinder, "Offshoring: The Next Industrial Revolution?" Foreign Affairs 85(2), March/April 2006, pp. 113-28.

  18. Comments from an old programmer by Animats · · Score: 5, Insightful

    As an old programmer, I'm not too impressed with that advice.

    It's important today for a programmer to understand how top management thinks. Read the Wall Street Journal and the Economist. After about a year, both will start to make sense, as it takes about that long for all the major subjects to come around once or twice. Eventually, you'll probably want to move into management.

    I'm not sure how much low-level knowledge really matters today. I understand what's going on down to the level of what happens in the wafer fab, but that's more because I'm in Silicon Valley. Understanding programming at the C level, definitely. At the machine code level, that may be too much detail to learn. A general notion of modern CPU architecture is useful; you should understand what caches do, why cache misses kill performance, and the implications of this at the program level. Detail beyond that level probably won't help you much. Understanding how an adder works is irrelevant to programming today.

    It's probably more important to understand networking in some detail. Understanding Ethernet, DNS, WiFi, TCP, PPPoE, etc. is necessary, because they all can give trouble and you may have to diagnose that trouble.

    I have to agree about the long-term value of UNIX knowledge vs. Microsoft-related knowledge. I first used UNIX in 1978, and programming on it has changed surprisingly little since then. We still have "make", we still have source control with check-in and check-out, and we still have a command line. And it doesn't go away. Since first using UNIX, I've used a half dozen other systems, most of them now defunct. Some were better. I keep getting forced back to UNIX, because it's still there after the others go away.

    Asking for code samples from job applicants doesn't seem to work. A few years ago, I was asking for "a thousand lines of C++ code you're proud of." Few programmers could come up with much. Reading the code was sometimes painful. I sent one back with the note: "Your first buffer overflow is on line 22. Thank you for your interest."

    Learning new programming languages isn't that hard, once you've learned a few different ones. What takes a long time is learning the quirks of a library. Today, each programming language comes with an library API with a few thousand objects and calls, some of which work reasonably. Finding out about the ones that don't is the most time-consuming part of learning a new environment today. This has led to a "ritual/taboo" style of programming, where huge books give sequences of code ("incantations") known to work, rather than development from first principles. This is the main source of career lock-in today. Be aware of that.

  19. Bullshit by c0d3h4x0r · · Score: 0
    There are now no interesting non-networked applications.

    Bullshit.

    Counterexamples:

    • 3D rendering/animation creation software
    • Photoshop, Illustrator, and other image editing/creation software
    • VirtualDub, Premiere, and other video editing/manipulation software
    • Protools, Cubase, Cakewalk, tracker software, and other audio/music editing/creation/manipulation software
    • Video game emulators
    • Computer emulators
    • Computer games
    • Desktop PC operating systems
    • Desktop finance management software
    • MS Office and OpenOffice
    • Tools for circumventing DRM and other technologies that abuse consumer rights
    • Driver development
    • Embedded device development
    • ...etc...


    Just because something isn't part of the "networked OS! AJAX! Live.com and Google! It's all about the network! Woo-hoo!" hype, that doesn't mean it's unneeded, not useful, uninteresting, or has exhausted its potential.

    There's still a LOT of room for improvement in desktop software and OSes that has nothing to do with a focus on networking features, and that's still very exciting stuff to work on.

    --
    Moderator hint: a comment is neither "Flamebait" nor "Troll" if it is true.
    1. Re:Bullshit by smellotron · · Score: 4, Insightful

      3D rendering/animation creation software
      Photoshop, Illustrator, and other image editing/creation software
      VirtualDub, Premiere, and other video editing/manipulation software
      Protools, Cubase, Cakewalk, tracker software, and other audio/music editing/creation/manipulation software

      You just listed a bunch of applications that are very CPU-intensive and "extremely parallelizeable". That is, every single one of those applications would be great to distribute. All modern production-level renderers operate on clusters (renderfarms). Apple's Logic software (similar to Pro Tools) supports distributed processing.

      Any digital artist would *love* to have even a small cluster available to do previews... while Maya et al have very good OpenGL previews, there's never enough CPU power for computer graphics (and I believe there never will be).

      Computer games
      Desktop finance management software

      You don't see any benefit of networking these applications? Maybe for a person's own finance management software a network would be overkill, but any company with more than 1 person handling finance management benefits from a remote data store and thick clients. Maybe you always play single player games, but I occasionally play StarCraft with a friend. Across a network.

      Network != World Wide Web

    2. Re:Bullshit by Anonymous Coward · · Score: 0

      and systems with hard real-time requirements? my team develops weapons control systems; i beg you to show us how we can AJAX our way to renderfarm bliss.

  20. There are two different kinds of programming... by sirwired · · Score: 1

    Really there are two different kinds of programming in the world, of which Mr. Allison only regularly traffics in one.

    A small minority of programmers do things like write Operating Systems, Protocol Stacks, Embedded Systems, or ever have to give a flying fig about the POSIX spec. (Or the Windows counterpart, for that matter.) These people are well served by CsC degrees, a fondness for algorithms, CPU Arch. knowledge, a current IEEE membership, etc.

    This is the sort of code created by what is generally referred to by the "tech industry". It is a pretty fair-sized industry, but is dwarfed by...

    Corporate IT programming. The gigantic majority of code used in this world is not written by technology companies. It is written by folks working in corporate IT departments, small application shops, etc. These are folks that toil day in and day out in DB languages, VB, COBOL, the AJAX and LAMP stacks, etc. These folks really don't need to spend a great deal of time learning basic principles, because processor architecture really isn't relevant to SQL or LAMP. These folks can get by with a Community College degree where they will either learn to program properly, or not.

    Both kinds of programmers can show great passion for work, both kinds can turn out really great code, or really pathetic code. The world certainly has need for both kinds or programmer, but tends to use a LOT more of the second. Look at job listings... how many openings are there for SQL, AJAX, COBOL, etc. gurus, vs. Low-level OS programmers?

    Some of Mr. Allison's advice applies to both kinds of programmer. Certainly your resume will never be hurt by contributing to community-based projects, but learning the language-of-the-week can be far more lucrative skill for an IT programmer than burning time learning about processor registers.

    For the record, I work in support, not development, but I work at a level low enough that I would be closer to the first kind of programmer, not the second. I eat bit-wise protocol traces for breakfast, chew on ANSI standards for lunch, and end the day with a hearty meal of high-speed network topologies capped with dessert of an IEEE journal or two.

    SirWired

    1. Re:There are two different kinds of programming... by smellotron · · Score: 2, Insightful

      A small minority of programmers do things like write Operating Systems, Protocol Stacks, ... These people are well served by CsC degrees, a fondness for algorithms, CPU Arch. knowledge, a current IEEE membership, etc.

      Add to that list anything related to scientific/numerical computing. Dynamic meshes for physics simulations, image/video processing, etc.

      The gigantic majority of code used in this world is not written by technology companies. It is written by folks working in corporate IT departments... These folks really don't need to spend a great deal of time learning basic principles, because processor architecture really isn't relevant to SQL or LAMP. These folks can get by with a Community College degree where they will either learn to program properly, or not.

      Software developers of business applications tend to fall on their faces if they're just "programmers". That, or their applications never get big enough. My interests lie largely on the "softer" side of Computer Science (heavy interest in software engineering/design/architecture and human-computer interactions), but I certainly think a full Computer Science program makes a big difference. Application developers still need to address issues like avoiding deadlocks, transactional safety, algorithms, and efficient data structures.

      Maybe in the future the Computer Science degree will be separated from the Software Engineering degree (much the same as Computer Engineering is separate, though sharing similar roots), but for now, a Computer Science degree is still the best place to study effective software development. Honestly, the structure of a lot of software (likely written by the folks who don't how "basic principles") makes my eyes bleed. Someone with that sort of education and solid domain experience coming into a small company could easily match the productivity of 3-4 run-of-the-mill programmers.

    2. Re:There are two different kinds of programming... by jamesmrankinjr · · Score: 1

      It is written by folks working in corporate IT departments, small application shops, etc.

      Should read "...is written by folks working in Bangalore, Hyderabad, or other low wage locations."

      -jimbo

  21. Not bad advice by Anonymous Coward · · Score: 0

    Not too bad advice, but some key points seem to be missing.

    1. Get a degree or some sort, in ANYTHING to fall back on. Computer Science is still useful, being a branch of mathematics and all.

    2. Do not let a n employer stomp all over you, (ie: EA, most game software houses). They don't own you, just your time from 9-5.

    3. Consider getting an engineering degree, in software. It's all the fun of programming, but you get to tell programmers what to do.

  22. How to Be Better Than 99% of Developers by Anonymous Coward · · Score: 0

    Young programmers, here is how to be better than 99% of your competition: buy and read "Code Complete" http://www.amazon.com/Code-Complete-Second-Steve-M cConnell/dp/0735619670/ref=pd_bbs_sr_1/103-2943223 -4107013?ie=UTF8&s=books&qid=1176100440&sr=8-1.

  23. loving what you do by burdalane · · Score: 1

    Sure, it's great to love what you do, regardless of money. Yet does that really compensate for having to go to a place every weekday at a certain time, spend 8+ hours doing that activity, follow orders, ask permission to take time off, and be unable to live in material comfort if you decide to stop doing it?

  24. Everyone missed the scariest part by spotchka · · Score: 1

    The scariest part of that article is not what coding we will be doing in ten years, it's the comment from the high-level executives from the corporation. They essentially wanted to get rid of the democratically elected government:

    I once had to listen to several high-level executives (for a previous company that shall remain nameless) waiting for the private corporate jet complain how inefficient it was that the country was run by democratically elected politicians as "they just didn't understand business".

    Lift your eyes from your monitor and WAKE UP!!