Forgot your password?
Programming IT Technology

Advice For Programmers Right Out of School 469

Posted by Hemos
from the words-of-advice-for-young-people dept.
ari1981 writes "I recently graduated from school with a CS degree, and several of my classes were very theoretical in nature. There was some programming, but it seems not as much as in other schools. I'm currently working at a company where I'm doing primarily c/c++ app development on unix. But as I read slashdot, and other tech sites / articles, and realize for some of the software being written nowadays, I would have absolutely NO IDEA how to even begin writing it. I remember first time I saw them, I thought console emulators were really cool. After my education, I have no idea how someone would begin writing one. With the work I'm doing now, it doesn't seem I'm going to be using (or creating) any of the really cool technology I hear about. How did everyone here begin learning / teaching themselves about different aspects of programming, that they initially had no clue about? How did you improve? Programming on your own? Through work?"
This discussion has been archived. No new comments can be posted.

Advice For Programmers Right Out of School

Comments Filter:
  • by eldavojohn (898314) * <> on Monday December 11, 2006 @11:29AM (#17194676) Journal
    I'm just going to throw something out there about your attitude towards computer science. I thought console emulators were cool also but I never took the time to dive into how they worked. I did take the time to dive into some OSS projects (like Weka) and find out how they work.

    While this wasn't what pulled me into computing, it may be your addiction. Here's what I would suggest doing--take a well developed open source emulator (you know, like an NES emulator []) and pick apart the source tree. You might find that the code is obviously doing some low level translation of the ROM which essentially changes its executable language to be IA32 or some such thing. It may be that you don't understand the architecture of the NES itself and therefor you can't really develop this yourself. So there's some insider information you lack but it will still be a good learning experience and may prompt you to figure out how to A) dump ROMs and B) reverse engineer a console architecture. Even if these are fruitless searches, how far you're willing to go will be a good indicator of whether or not CS is for you. Yeah, I hate to say this but I know people with CS degrees that simply don't have the debugging mentality to be programmers. A simple test is to think back to the times you saw something neat. Did you ever have a strong internal urge to find out how it worked or to try and modify it to augment its task?

    But as I read slashdot, and other tech sites / articles, and realize for some of the software being written nowadays, I would have absolutely NO IDEA how to even begin writing it.

    Fear not your own ignorance. Only fear your acceptance of it. I am confident that if I wanted to build an emulator I could. I personally find other things more interesting but you just have to buckle down and really pick it apart and look for answers. As I said above, these emulators might have proprietary reverse engineering so these backwards black boxes might not be the best place to start as you may be met with frustration. On top of that, the newer consoles are now fighting a war & implementing encryption scheme which just makes the emulator all that more complicated. Why don't you pick a project like Firefox? Get the source, find out what the common developing environment is and step through the code when you visit a page. That's where it all starts.

    Most importantly, you don't need to do everything from the ground up. It helps to know everything that's going on below the abstractions you sit upon but you don't need to think about that every time you write code. Learn to use libraries & frameworks. To quote Salvador Dali: "Those who do not want to imitate anything, produce nothing." I couldn't start writing an emulater either. But if I looked at the source trees and structures of the more popular ones out there, I'm damn sure I could figure it out. That confidence I have in myself is infallible and that's important to me. Sorry to sound like Dr. Phil but you asked for my opinion.

    There are different tricks to different applications. Some are more simple than others. In my opinion, the less tricks you need to get started in a language, the better. Because we're not all world class magicians (although every language has some players that could rock your world in said language). This is why Java, while not as efficient as C, is probably taught to you first. There are very few tricks one needs to know in Java. But you know what? Java is still quite useful. Those responsible for implementing it did a decent job and now the web service programmer needs to know very little about them because configuring them has been abstracted and made easier by many UI & IDE tools out there. But web services are a very practical and widely accepted concept out there today. In fact, pay the bills by writing some very inane web se

  • Write new code (Score:5, Insightful)

    by stibrian (848620) on Monday December 11, 2006 @11:31AM (#17194702)
    If you want to be a coder...

    write more code of your own
    write more code
    read more code
    read LOTS of other people's code (DL a smallish OSS project at first, then larger ones).

    rinse, lather, repeat.

    If you're concerned that you're not learning "cool new things" on the job, learn them off the job. Your destiny is your own, as hokey as that sounds...

    love your work.
  • by Steepe (114037) on Monday December 11, 2006 @11:32AM (#17194726) Homepage
    Figure out what you need, and get some good libraries.

    No one codes anything from scratch anymore. You combine libraries together and thats about it. :)

    You ARE in the correct spot though, doing C / C++ actually teaches you how to code a bit. Here we use mostly java and some .net, which is not very conducive to any heavy programming.

    Once you get some experience, start looking for jobs that fit the bill of what you want to do, find some OS projects doing what you want to do and volunteer to do some coding in those. Take the crap work, that teaches you the hard stuff. The rock star stuff comes later.
  • by AKAImBatman (238306) * <> on Monday December 11, 2006 @11:36AM (#17194802) Homepage Journal
    I recently graduated from school with a CS degree, and several of my classes were very theoretical in nature. I remember first time I saw them, I thought console emulators were really cool. I have no idea how someone would begin writing one.

    Yes you do. You just don't know it yet. (Assuming your school wasn't out and out terrible.) There's a huge divide between theory and practice that every new programmer has to overcome. The best way to overcome it is to dive in and learn about the practical designs of today's technologies.

    For example, you want to write an emulator. Many of the early game consoles were based on the 6502 microprocessor. If that scares you, it shouldn't. Read this webpage: []

    It will introduce you to 6502 assembly. It explains not only the text commands you can use, but also the hex codes that will be output by the assembler. You can get an assembler like DASM [] and try it out for yourself. Try writing a simple program like:

      lda #2
      adc #2
    Next, run it through the assembler. Open it in a hex editor [] and you should be able to see the direct mappings between your code and the program output. If you target a specific platform like the Atari 2600, you can use an existing emulator with a debugger like Stella [] to watch your code execute line by line.

    Remember, learning doesn't end when you exit school. It just begins. So start digging up everything from reverse engineered documentation to documents put out by standards commities like the IETF's RFCs, the W3C standards, and the ECMA standards. You'll gain a much greater appreciation for how things work after you take them apart and understand them. ;)
  • by digitalhermit (113459) on Monday December 11, 2006 @11:37AM (#17194814) Homepage
    A few years ago I had to learn Perl in a hurry. There were some REXX based apps that needed to be moved and I got tasked with the job. In a few weeks I went from knowing that Perl was a useful scripting language to actually having to teach an introductory Perl course for the other team members. The translation process was extremely helpful. For one, it was doing useful stuff, not just what the textbook author thinks is appropriate. Second, it forced me to use "proper" methods if only because the REXX scripts were fairly mature and I needed equivalent stability.

    Teaching it was also useful because it made me convert awk, korn, bash and sed functionality *and* taught me that Perl wasn't the slowpoke I'd thought an interpreted language would be.
  • by Anonymous Coward on Monday December 11, 2006 @11:37AM (#17194828)
    A computer science degree is worthless if all it has you doing is ambling through by passing written exams; algorithms and formal languages are a single area of computer science.

    Aside from not going to a school that has not redesigned their curriculum since 1985, one possible "fix" would have been to get non-classroom experience either outside the school or in a research lab.
  • Yoda advice (Score:4, Insightful)

    by Anonymous Coward on Monday December 11, 2006 @11:38AM (#17194838)
    No. Try not. Do... or do not. There is no try
  • by (67146) on Monday December 11, 2006 @11:41AM (#17194894) Homepage
    It takes 10 years to gain 10 years of experience. No short cuts.

    You need to write a mountain of code before you reach the level where you can debate the finer points for or against C# / Java / Python / LISP... You will learn the most from your mistakes, so go forth and screw it up. Do it often. And then fix it. Each iteration will make you better, and remember it takes time.

  • Fear. (Score:5, Insightful)

    by Aladrin (926209) on Monday December 11, 2006 @11:41AM (#17194896)
    " I would have absolutely NO IDEA how to even begin writing it. "

    That's called 'fear' in the world of programming. Instead of digging into an open source project, or just jumping in and seeing what you could do, you turned away, and asked others to make it easy for you. Learn to recognize your fear, and you can master it.

    All programmers feel it, some of the best just mastered it without ever thinking about it. None of us were handed this information on a silver platter. If you spent enough time in college to learn enough programming to be a master, you'd be retired when you were done.

    The fastest way to learn programming is to jump in, not to go to school.
  • by everphilski (877346) on Monday December 11, 2006 @11:42AM (#17194908) Journal
    1) Jump right back into school and get your masters. I did it. Zero regrets (Heading to my last final exam in a few hours... I haven't even graduated and the rewards are in plain sight, not to mention the rise in pay next review)

    2) Reading - get books. Educate yourself. Self-starters are valuable.
    3) Writing - don't just read, but practice by coding. It's the only way to learn. The more senses you invoke the more you comprehend.
    4) Arithmatic - (depending on your field, but for 99% of them...) keep up on your math skills. Sharp math skills will make your job easier ..
    I've been employed for a year, so I'm fairly fresh in the field but those are the things I've found and am taking to heart. They seem to work for me.
  • by Ontology42 (964454) on Monday December 11, 2006 @11:42AM (#17194910)
    Ok, Myself, well I was "Perscribed" the use of a computer for my deslexiya at 7 years of age. Since I'm almost 30 now that was a long time ago. Bieng Deslexic (IE: a visual thinker??) and completely unable to spell, despite the horrid use of speak and spells. I stumbled into boolen logic via a video game. From there I found out about Basic, C/C++ and Delphi. Now the adivce above is excellent however if you are new to the field it's always a good idea to study the classics: [] Now I know it's a bit dated at this time, hopefully your school prepared you to think, it's not a university's job to give you "Job Skills" the education of the Computer Science graduates is basically to teach them how to Learn and Re-learn everything very quickly since the field you are going into has a habbit of reinventing itself every 18 months (thank you gordon). As to what or how you should learn, I highly suggest you start with the Unified Modeling language. It's a good place to start, then drill down. Good programmers always tackle large problems as a series of smaller ones. And if your using C/C++ remember to focus on security and creating a portable API!!! Happy Hunting
  • by ColonelPanic (138077) <> on Monday December 11, 2006 @11:43AM (#17194930)
    If you want to really learn the craft of programming, here are
    some tips. If you don't like them, stick to what you're doing
    and be happy.

    1) Learn assembly language. Play with it. Think in terms of
          what you can and cannot do with it. Read the -S output of
          your compiler and understand it in terms of your source.
    2) Play with algorithms. Can you code up a heapsort without
          referring to a book? Can you do it in assembly? Read Jon
          Bentley's "Programming Pearls".
    3) Know your platforms' hardware and software. Install a
          from-source Linux distro like Gentoo. Configure, build,
          and install kernels from source. Play with the kernel;
          even a simple thing like adding your name in a printk()
          can be exciting.
    4) Iterate. Keep current on the basics. Do you really know
          your programming language? If you don't know how something
          works, read up on it and read the sources. It's all just
          ones and zeros.
    5) Read "Hacker's Delight". Slowly. Enjoy it.
    6) When low-level stuff gets to not be fun, play with high
          level things. Write some Emacs Lisp. Learn Prolog.
          Play with Squeak. Think about how they're implemented.

    I have been doing this for a long time and I cannot emphasize
    strongly enough the importance of refreshing your basic skills.
    And play. Computers are fun. I have written compilers and
    kernels from scratch, worked on instruction set architectures,
    and a bunch of other stuff, and haven't yet exhausted the fun
    that computers can be.

    But they're not fun for everybody. If all this sounds dull to
    you, it probably will be, and maybe you should pursue some other
    hobby while pounding out C++ to pay the bills.
  • by Weaselmancer (533834) on Monday December 11, 2006 @11:46AM (#17194978)

    College teaches you how to learn. Once you realize that, your education truly begins.

  • by Deluxe_247 (743837) on Monday December 11, 2006 @11:46AM (#17194982)
    Do whatever works best for you. Some people swear by reading coding books, improving your math skills (especially if you are interested in graphics programming) - and others tell you to work off other peoples code or take a class or something... I think working with other coders gives me the most benefit... As long as you aren't shy about asking 'why' and doing some legwork in looking things up yourself. When you are surrounded by people who have been coding for 10-20 years not tapping that resource is just stupid. Sure, they might have 'their way' of doing things, but like you should have learned in Comp Sci, there's more than one way to fry an egg (write some code, mix a drink, etc.) You get the point. Learn the concepts, look over other peoples code to 'see what they were doing', work on a project that will give you exposure to subject matter experts in areas you want to learn more about, and you'll be on your way. And honestly, I *DO* believe reading is beneficial. Even if you don't feel like you learn very well that way (some people dont), books are a great resource to learn new things or use as reference material. You might be overwhelmed at first, but the more effort you put into developing your skills, the more you will get out of it.
  • Hmmmmm (Score:4, Insightful)

    by Jerf (17166) on Monday December 11, 2006 @11:49AM (#17195024) Journal
    If your education truly focused on theory, you ought to know more about writing an emulator than you think. An emulator is basically just an interpreter/compiler. Emulators often then use a whole bunch of tricks to speed things up, but at their core, all they are doing is taking in the memory image of a program and interpreting it in the context of a software implementation of the hardware. In theory, writing a console emulator starts out the same as writing any other interpreter, and while there may be special graphics or audio tricks you have to use, much of the rest of the optimization issues looks just like an optimizing compiler. Emulators have been doing Just-In-Time compilation for a long time now, for instance.

    There are many details in a real emulator, but then, there are many details in GCC, too. The fundamental structure is still there.

    If you missed compilers in your "theory heavy" education, that could be a problem. (I think compilers ought to still be a required course; the requisite skills form the basis of far, far more programs than just your C compiler. Almost every text to text converter is better written as a compiler than a series of regexes or some other such hack, and with proper tools and the understanding to use them it's usually easier, too.)

    While you may not quite know enough to correlate them, many other programs use fundamental constructs from computer science too.

    What you probably lack is experience, and there's only one way to get that. Fortunately, there's a large body of open source to study. As others have said, grab and interesting program and read it. As I haven't seen others say, after you've poked around for a bit, take the program and make a change to it. Emulators are probably not the best target here because at best you'll probably just degrade the performance, but who knows? Maybe SNES will let you plug in to their resolution upsampling framework easily and you can add your own interpolator or something. You'll find the first change is harder than you think, but this too is a valuable skill you'll use over and over again in real life; you will frequently be called on to make a change to a codebase you don't really understand. (One could argue that that is actually the general case....)
  • by Moggyboy (949119) on Monday December 11, 2006 @11:50AM (#17195044)
    I can honestly say that I learnt more in the first six months of working than I did in 4 years of university, but I think the crux of getting a university education is learning how to learn. At my university (RMIT in Melbourne, Australia) we learnt a grand total of 6 languages over the first three years: Ada, C, C++, PERL, Java and LISP. Each student was expected to write a reasonably complex piece of software in each of these languages within 2-3 months of seeing it for the first time, gearing up with harder and harder assignments each month.

    While I wouldn't say I came out of the experience with as a guru in any of these languages, I sure knew how to go about learning a new one. I also learnt lots of stuff that can be reapplied to every project you ever work on, i.e. design principles, design patterns, OO programming, defensive coding, etc. With every project I've worked on since then, these general concepts become honed, and you learn lots of neat tricks over the years that cumulatively turn you into someone that can work smarter, not harder.

    There is always gonna be stuff that's outside your realm of experience; that you look at and think to yourself, WTF? Don't let it get you down if you have to work up to it. These things take time.

  • by flynt (248848) on Monday December 11, 2006 @11:52AM (#17195078)
    This is a great comment. No one is born knowing these things. It is not surprising that CS undergraduate program did not teach you exactly how to write an emulator. But as parent said, don't be scared of not knowing. None of us knew anything until we sat down, invested serious time and thought, and actually did something about it. You don't learn everything overnight, that's not the point. But if you have a goal, just dive in and see where it takes you. You probably know more than you think, just don't fear fear.
  • CS vs Programming (Score:5, Insightful)

    by grendel's mom (550034) on Monday December 11, 2006 @11:52AM (#17195088)
    A few suggestions:

    1. Don't confuse "Computer Science" with commercial programming. They are NOT the same thing.

    2. You will soon realize that coding is a far smaller portion of your job then you expect. The coding portion decreases as you move up the food chain.

    3. Do not ignore the business/finance side of your job. The business side keeps you employed.

    4. As you learn more, you will realize how little you actually know.

    5. Your current position is nothing more than a software assembly line job. All of those "cool" technologies are being developed by more experienced engineers.

    6. "Engineering" software and "programming" are more different than you realize.

    7. Coding is the easy part. You can teach a cat to bang out code. It takes an artist to design good software.

    8. You have one of the best jobs in the world. Your technology base allows *you* the ability to build wondrous applications. Use it!

    9. Have fun coding. Make it a personal challenge. Reallize a job is just for paying the bills. Your much more free than you realize.

    Good luck.
  • Re:Refund? (Score:1, Insightful)

    by Anonymous Coward on Monday December 11, 2006 @11:53AM (#17195096)
    Sounds like you should ask your school for a refund.
    Remember: if you're going to ask a question for Slashdot and you aren't afraid to be realistic and reveal you have shortcomings, the only highly modded comments will be the ones making fun of you.

    Seriously, you pretty much fit the Comic Book Guy stereotype of a nerd with no social capabilities who only feels good when he makes fun of other people. Not everyone knows everything about everything, you know. If you told me you only have Pi friends, I wouldn't be surprised.

    I wish the stereotypical nerd was helpful. Instead our stereotype is that of an asshole.
  • by mveloso (325617) on Monday December 11, 2006 @11:54AM (#17195110)
    Starting to write a piece of software, especially an application used by end users (or, horrors, the public) is incredibly difficult. They don't teach it in school because the number of written-from-scratch applications is small. It's complicated, error-prone, and you don't know if you made the right decisions until weeks, or months, later.

    It's exacerbated by the fact that you actually need to ship your product. You don't have the luxury, usually, of sitting around arguing the finer points of various architecures and algorithms. What toolset should you use? What framework? Libraries? Product dependencies? OS?

    All of those require tradeoffs, and incur costs that may not be known for weeks, months, or years.

    In fact, there are no right answers. There are things that make life easier or harder down the road. Unfortunately, those of us that have written multiple apps from scratch have a hard time explaining what the design choices were or even how to do it. Some things work, some things don't, and depending on your application, budget, and timeline you choose differently. If you're good, you keep up with the various technologies (on at least a passing basis) so you can learn new stuff/ideas/concepts that may help.

    What are some of the factors to consider? Some simple ones are:
    deployment - how do you deploy it?
    Maintenance - how do you maintain the applcation?
    How do you updates?
    Are there enough people who know what you're using to hire? If not, is it easy to learn?
    What features are requested, but not in this release? You can architect today for functionality tomorrow.
    Toolset: are there too many moving parts? How many moving parts is too many?
    Certain technologies, like J2EE, .NET, LAMP lock you in to a way of doing things. Is that OK?
    If you use new stuff, is it stable enough to actually use in real life?

    Then when you start writing your app, what do you start with? Again, it depends. Some people design and write from the inside out (internals to GUI), and some write from the outside in (GUI to internals). A user app should do the latter, since the capabilities of the UI have to be supported by the back-end. Blah blah blah.

    In short, you have to learn by doing, making mistakes, and doing it again. Learn from other programs, etc, by asking: why do they do things that way? You can see design decisions and how they impact the application everywhere.

    Yeah, it's rambling, but it's late for me.
  • by chris_mahan (256577) <> on Monday December 11, 2006 @11:59AM (#17195186) Homepage
    Calm down. I work in a cubicle as a programmer for a fortune 500. I completely agree with everything he said.

    > I guarantee I'm a much happier person than you. Oh, by the way, go fuck yourself asshole.

    That is by far the most contradictory statement I have ever read on slashdot. (and I've been coming here for many years)
  • by Bilbo (7015) on Monday December 11, 2006 @12:11PM (#17195354) Homepage
    Regarding your comment about programs rarely being built "from the ground up":

    There has only been one program ever written from from scratch, and that was "Hello World." Everything other program has been cut-n-pasted from that.

    (Well, that's true at least from the advent of "high level" languages like "C", but it's probably true with respect to most Assembly programs too.)

  • Re:Refund? (Score:5, Insightful)

    by The_Wilschon (782534) on Monday December 11, 2006 @12:19PM (#17195490) Homepage
    You DO realize that he got a Computer Science degree, right? Not a programming degree. I realize that the name CS is usually used today to tart up a programming degree and make it sound special, but a Real CS degree is much closer to a degree in Mathematics (and not applied math...) than it is to a degree in programming. It does sound like maybe what he was looking for was a programming degree, but it was his responsibility to figure out before he started whether his school offered CS or programming under the CS name. Asking for a refund would definitely not be appropriate here. Actually, if I went to a school that offered CS, and found I had a programming degree when all was said and done, I might ask for a refund then. But not when they say its CS and it turns out to actually be (gasp!) CS. That's like going for a Physics degree, and complaining when they don't teach you engineering. If my Physics profs tried to teach me engineering all the time, I'd be looking to transfer somewhere with a REAL Physics program. Not that there's anything wrong with engineering, but a) it isn't what I want to do, and b) it isn't Physics.
  • Re:Write new code (Score:3, Insightful)

    by pjwhite (18503) on Monday December 11, 2006 @12:20PM (#17195498) Homepage
    If you want to learn to write books, you don't start by writing a book, you start by reading other peoples books. So, before you start writing code, read, read, read!

    Well, that's one theory I heard about, which seems good enough on the surface, but in reality, you'll probably read just enough to find that one algorithm or method of doing something that you're looking for. If you want to write a terminal emulator, go grab the source code for a terminal emulator and see how they did it.
  • Re:Write new code (Score:4, Insightful)

    by Savage-Rabbit (308260) on Monday December 11, 2006 @12:21PM (#17195514)
    If you want to be a coder...

    write more code of your own
    write more code
    read more code
    read LOTS of other people's code (DL a smallish OSS project at first, then larger ones).

    rinse, lather, repeat.

    If you're concerned that you're not learning "cool new things" on the job, learn them off the job. Your destiny is your own, as hokey as that sounds...

    love your work.

    That's pretty sound advice.

    • Personally I'd say that for the first few years you'd be better off picking jobs with companies where you are likely to pick up disciplined, professional development practices, marketable skills and knowledge than you will be chasing solely after the money. Also don't allow your self to become too specialized, you want a broad skill-set. Excessive specialization is leads to trouble.
    • Learn things you don't learn at work by setting up your own OSS project, joining one or if you absolutely can't stand doing something for no profit set up a shareware product of some sort to keep your self in practice. Half the jobs I have gotten I got because of knowledge I gained on my own time.
    • Another thing to keep in mind is that whether you are writing code at work or privately one of the best ways of learning about software design, as the parent post suggested, is to look at other people's code (think: sourceforge). Doing that also allows you to compare different approaches to solving design problems. For example writing a daemon in C vs. C++ vs. Java vs. Perl. Some approaches will be awful others more sensible but you can learn something from all of them. Even comparing the different approaches people take to solving the same problem in two projects that both use C++ can be interesting.
    ... and yeah it helps a lot if you love what you do for a living. In my experience some employers will actually consider hiring applicants with less experience if they are enthusiastic about their occupation.
  • by The_Wilschon (782534) on Monday December 11, 2006 @12:27PM (#17195610) Homepage
    doing C / C++ actually teaches you how to code a bit
    Except it teaches really terrible programming practice in general... Only partly because it doesn't enforce good practice the way java tries to (gag!), but more because even with all of its horrendously overblown (I'm talking about C++ now) set of features, it still doesn't provide the kind of features that you really need to organize everything in a nice intuitive easy to understand (and therefore maintain) manner. When I spend more of my time fighting the language than actually getting anything good done (and yes I do this in Java as well), there is a problem. The language should be powerful and flexible enough to allow me to organize things in the best way for the problem at hand, rather than the really quite rigid few ways the language designers came up with.

    And I'd much rather do heavy coding in java or .net (or a few other languages...), simply for the automatic memory management. Manual new/delete is the cause of more impossible to find bugs..... And garbage collection is really quite efficient. Except in some very few niche cases, or unless you really are the rock star, automatic memory management is going to be more efficient than manual.
  • by Richard Steiner (1585) <> on Monday December 11, 2006 @12:30PM (#17195676) Homepage Journal

    1. Don't confuse "Computer Science" with commercial programming. They are NOT the same thing.

    Especially these days. When I received my degree, all IT-related degrees were CS degrees at a fair number of schools, and one simply chose a specialized track (systems, scientific, business) after finishing the CS core, but that's not the approach used at many schools today.

    I liked the mix of practical and theoretical classes I took in the program I went through, though, since I think I've derived a lot of benefit from both types of classes over the years.

    2. You will soon realize that coding is a far smaller portion of your job then you expect. The coding portion decreases as you move up the food chain.

    Yes, unless you're a dedicated code monkey (something I've never personally encountered), you will be expected to do design work, create specifications, do support, talk to customers, help to coordinate tasks on complex projects, etc.

    3. Do not ignore the business/finance side of your job. The business side keeps you employed.

    Probably sound advice. In a large IT shop, you won't necessarily USE that type of knowledge in an overt manner, but it never hurts to be able to understand the business process and how it relates to your current position, and in future positions it could be tremendously helpful.

    4. As you learn more, you will realize how little you actually know.

    There's always someone else out there who's been doing it longer or better than you have. Or both. :-)

    Pay attention to them -- such people are valuable teachers and resources, and I've learned a lot from people like that myself. Some programming tricks might be as old as YOU are. :-)

    5. Your current position is nothing more than a software assembly line job. All of those "cool" technologies are being developed by more experienced engineers.

    In all the shops I've worked in over the years, we NEVER had folks who did software in an assembly-line manner. Even folks like me right out of school were doing (mentored) design work for the live system. Other shops may be different, obviously, but even the folks I've seen who were writing software from a func spec that someone else created had a certain amount of latitude in terms of its actual implementation (even if screens and inputs/outputs were all predefined, the internal structure was often left up to the coder).

    Don't be afraid of trying to create things on your own. I've seen folks right out of school make a huge difference by writing a little utility or by applying something they learned from another platform, and sometimes even something small can make a large difference. Experienced people are often very smart, but their tred-and-true experience (while often relevant) can also blind them to new approaches at times. I'm guilty of that as much as anyone at times. :-(

    6. "Engineering" software and "programming" are more different than you realize.

    Both should involve a formal process (although not all processes which people have in place are constructive or even useful). However, real "engineering" seems to rarely apply to software development. I still haven't decided if that's a good thing or a bad thing overall.

    7. Coding is the easy part. You can teach a cat to bang out code. It takes an artist to design good software.

    Absolutely. The top priority should be readable code that is easy for someone unfamiliar with the gory details to maintain. That means relevant comments in the source and (hopefully) a good set of programmer support documents written in parallel with the software. I've had the privilege to work in two shops where that was done quite well, but that's the exception, not the rule.

    My appro

  • by hachete (473378) on Monday December 11, 2006 @12:32PM (#17195698) Homepage Journal
    fix OTHER people's code. It may not be glamorous, it may not bring in the big payola but hey, it has it's own charms. And it makes you write more robust code as well.
  • by Maxo-Texas (864189) on Monday December 11, 2006 @12:40PM (#17195848)
    If you absolutely love coding, read coding books to relax after hours, it's the center of your life, then you need to avoid big corporations unless their main business is selling a software product. The bureaucracy will smother out all your happy feelings. The funnest places to work are small.

    If you like coding, then your options are more open. Big companies often give you a shot at expensive training and new technologies.

    Take frequent breaks to save your hands. Get books on carpal tunnel and read them *NOW* before you develop problems.

    If you only "like" it, then learn about project management and when you get tired of programming you can move up instead of out.
  • by MasterC (70492) <cmlburnett@gm[ ].com ['ail' in gap]> on Monday December 11, 2006 @12:45PM (#17195900) Homepage
    College teaches you how to learn. Once you realize that, your education truly begins.
    College doesn't teach you anything but how to follow directions at a higher level. Seriously. If you didn't do what your instructor wants, what kind of grades do you get? Learning and learning how to learn are side effects that you have to take as your own initiative to accomplish. I would heartily agree that learning the material and, better yet, learning how to learn definitely make things easier but college (school, in general, actually) is about following instructions. If your prof expects you to know X and Y then you better know X and Y, but knowing Z is only of benefit to you.

    Coincidentally: work is the same. :) If you don't do what your boss wants, what kind of "grade" do you get? If you can do more (read: extra-curricular) and take initiatives (read: learning) then you're better off and a more valued employee.

    There are exceptions, of course.

    Independent study is where those learning skills come to fruition (this is more of a response to the thread than the parent post). No one to tell you what to do. No one to guide you. No one to test you. No one to make sure you aren't screwing up. Except yourself that is.
  • by tecnopa (931480) on Monday December 11, 2006 @12:45PM (#17195906)
    im in a similar position to you, just graduated with B.Sc. and working at my first "real" job. I came from a very research oriented background and was used to working on projects that were very COOL but not very practical. I think its unrealistic to expect to work on such projects immediately in the real world because, lets face it, you need either 5 years experience or AT LEAST an M.Sc. to even be considered for truly research oriented, paid positions. My advice to you, and what Im currently doing myself, is to find a company where you'll get lots of experience with real world, demand/quality driven programming. Go work for a company with good processes, where you can get your hands dirty. It wont be the most fascinating thing in the world, but it doesn't have to be your permanent career. Do that for 2 years, then either move on (if you're still not satisfied), or go back to grad school. Not to sound offensive, but if you honestly don't have any idea where to begin writing an emulator, then you probably dont have much shot of getting an "interesting" job right out of school. It doesnt mean you'll never get it, it just means not right now.
  • Re:Write new code (Score:3, Insightful)

    by spirality (188417) on Monday December 11, 2006 @12:52PM (#17196008) Homepage
    I agree with all of that. Joining a professional organization like The ACM [] or The IEEE [] and reading their journals is also a good place to get informed about some of the broader trends in the industry. This is not necessarily writing of code, but learning about the things that underly the code. Core ideas IMHO are much more important than code itself. When you reach a certain level the act of coding should become trivial, like picking up a book and reading it. Its the ideas behind the code that are interesting and what keeps us moving forward. I can't speak for IEEE personally, but I've been a member of ACM since my college days and have learned a lot from reading "Communications of the ACM".
  • Re:Refund? (Score:4, Insightful)

    by TheRaven64 (641858) on Monday December 11, 2006 @12:55PM (#17196054) Journal

    A real Computer Science degree should have taught him the principle of Turing-equivalence. It should have had at least some assignments expressing algorithms on Turing Machines, Unlimited Register Machines, Petri Nets, Lambda expressions, etc. The principles of converting between one universal mechanism for computation and another should be deeply ingrained. How do you prove that a model of computation is universal? You implement an emulator for an existing universal model of computation (typically a Turing Machine) in it.

    That covers the basic theory. Then you need to understand how a real computer works. Any half-decent CompSci programme should have explained the basics of a relatively modern architecture. From there, it's just a matter of learning the instruction set, memory layout, devices present and how to communicate with them; anyone who actually gets a CompSci degree should have the ability to read the relevant documentation and understand the architecture.

    Past the theory is implementation. The first bit of that is understanding how to parse an instruction stream. Any CompSci course that doesn't cover the automata theory required for this should be regarded with suspicion. Once you've parsed the instructions, and understand what they are meant to do, it's just a matter of implementing functions that handle them, which is time-consuming, but not conceptually difficult.

    Now, the emulator produced using these steps would be slow. I would estimate between 1% and 0.1% of the native CPU speed. Fortunately, on a modern CPU that is fast enough. If you want to get in to dynamic (JIT) recompilation and caching, it's a little bit harder, but the compilers course (plus some reading of the documentation for the target architecture) should provide the requisite knowledge.

    To me, it sounds like the original poster has sat through a Computer Science degree and managed to gain some of the knowledge but none of the understanding that it was meant to impart.

  • by Anthony Liguori (820979) on Monday December 11, 2006 @12:59PM (#17196116) Homepage
    Either you didn't pay attention or your school wasn't that good. Sorry.

    A "console emulator" can be a straight forward emulator in which case, you should know enough from just your basic architecture courses. Did you discuss instruction decoding and ISAs?

    Modern console emulators are probably Just In Time compilers. You should have had a compilers class and the prof should have at least mentioned binary translation. Even if they didn't, you should have spent a little time on JITs in an architecture class.

    A college education is not necessarily about knowing how to solve problems, but how to decompose a problem into a series of problems that you can then figure out how to solve. For a console emulator, that may mean that first you know you have to read about the architecture your emulation (what's the ISA, what are the components, etc.). Then you realize you have to parse the actual ROMs (here's where your automata/compiler background kicks in). Then either emulate each instruction (tedious) or do dynamic translation.

    If you wouldn't even know where to start, you didn't get the right education. I'd recommend trying to find a masters program or pick up some text books.
  • by Bamafan77 (565893) on Monday December 11, 2006 @01:00PM (#17196126)
    It takes 10 years to gain 10 years of experience. No short cuts.

    You need to write a mountain of code before you reach the level where you can debate the finer points for or against C# / Java / Python / LISP... You will learn the most from your mistakes, so go forth and screw it up. Do it often. And then fix it. Each iteration will make you better, and remember it takes time.

    I'm not too crazy about this attitude. You can certainly begin the debate before then. Sure you may be smacked down, but at least you'll be learning.

    Also, there's plenty of counter examples of people who've done cool things with far less than 10 years of experience. And there's also the people with one year of experience repeated 10 times.

  • by Anonymous Coward on Monday December 11, 2006 @01:05PM (#17196200)
    (posted anonymously of course)

    1) Make a decision about your work environment:
    Is this a company that you'd like to grow up in or is it something that pays the bills?
            There are some great companies with really smart people, where the environment fosters knowledge and growth. You will learn from others and will be given some latitude to explore your own ideas ..etc. This is where you want to bust your ass and really make an effort.
            And there are some other companies, where there is 3 'leads' for a programmer (trust me, I work at one!). Lead in my company means, a person, how just bounces around email, insists on being present at every meeting, and signing the programmer up for some impossible deadline, forcing the programmer to work long hours and weekends AND finally takes all the credit for your work in some fancy power point presentation. If this is your company, you should either consider moving to a better one or just treat work like, you know, WORK : like a 9-5 affair.

    2) Pick an area that your a passionate about and work on it.
              Are you passionate about user interfaces but your day time job is programming soul-less web services for an enterprise application? Then join an existing open source project. (I'd advice against starting your own, just yet. There are thousands of open source projects on SourceForge that were started out on a whim and stay stale after 2 weeks. I don't need a 100 incomplete, alpha version mp3 players, I need one or two kick ass ones). IN this example join some thing like KDE or Mozilla. Lurk in the mailing lists, learn, suggest _AND_ implement improvements. you will learn.
              It is important to pick an area/project that you are passionate about for this. Because when coming home after 6 hours of sitting in front of a monitor at work, the last thing you want to do is sit in front of your laptop for another 4 hours. But if you really like/care about the project, you will find a way to spend time on it.

    3) Pick an area that possibly might interest you and monitor its progress:
                      Lets say the field of Bio Metrics interests you. Join a news group and follow the industry progress. Who knows some day, your current experience and the 'domain knowledge' might lead you to do something on your own.

    good luck
  • Read, read, read (Score:2, Insightful)

    by kabdib (81955) on Monday December 11, 2006 @01:18PM (#17196396) Homepage
    Most of the really good people I've worked with have had either (A) a really good education and have read a lot of good books, or (B) they are self-taught and have read a lot of good books.

    It's just like school, really. Read. Do the exercises. There are tons of books (some even good) on how to write video game engines, for instance. (Just avoid the Sams "Learn game programming in 31 milliseconds!" crap). In the absence of helpful literature, well, I didn't know how games worked until I just sat down and wrote a few (a couple years later I had shipped several titles for a company you've definitely heard of).

    You could do worse than to join the ACM and take advantage of their online library of journals and proceedings. It's a super way to come up to speed on just about anything in computing.
  • by kinglink (195330) on Monday December 11, 2006 @01:19PM (#17196418)
    The most important decision to make now is "what do I want to do". It's a hard one, but start by looking into what field you want to go after? Game programming? Any that give you lots of money? IT?

    Next thing you need to do after deciding that is start focusing on it. If you want to be a game programmer, start programming your own game. A company that hires you won't just look at your education, they'll look what else you've done, and a big bonus is "self starting". It doesn't matter if you don't know how to make a finished game or a finished project you can learn how to do the final stuff, and most of the time they don't care. What will matter is that you've designed something and worked towards it. In addition the code can show the employers "I know how to code".

    If you want to go into IT start looking for work now. Anything you do outside of the field isn't going to help you too much in the long run, but be sure to learn as much as you can about networks and hardware for it (routers and so on, not just lan adapters). Try to learn Linux as well for IT, that might not help you but it's good to know it so you can work with networking apps with out dealing with the BS that Microsoft gives developers (dear god, what ever you do don't expect CSocket to be all you need for networking experience).

    If you want to make money start networking. And I mean P2P.. Or rather that's person to person. Talk to people who can help you get jobs in major companies. You want a job in finance to make the most money the fastest.

    Overall it's important to take a direction and start working towards it. The biggest mistake you can make is think your goal is to radical to start working towards it (something I had to learn.. Now I work at a video game company. What I always wanted to do.)

    The second mistake you can make is undervaluing your skills. Don't take a job for 24K, even if they promise a pay raise in 3 monthes (finance, personal experience.) Demand 40K a year at the minimum. Short and simple that's the bare minimum you deserve and that's even low. If you're in a good job, you should be making more.

    Also always be willing to move, that'll give you many more options, and don't be afraid to seek out big name companies to apply to. Nothing is wrong with apply somewhere expecting relocation expense. They should be provided.

    Don't worry if you get into something and don't like it. You're still learning and no one expects you to be a good coder yet, school is to teach you the basics, they'll train you to be the programmer they want (or they arn't worth working for).
  • Plastics. (Score:4, Insightful)

    by phliar (87116) on Monday December 11, 2006 @01:22PM (#17196470) Homepage

    I assume graduate school is not a consideration right now since you're working.

    Do you like tinkering? That is the essential skill/attitude. Everyone that I know who is happy and successful in software is a tinkerer. A hacker, in the old and honourable sense of the word. When we were kids (before computers, if you can believe that!) we amused ourselves with homebrew "chemistry experiments" and electronics and taking apart household appliances, especially clocks. Now we do the same thing but in software. (Most of us continue to hack in other fields as well, building airplanes and clocks and furniture.)

    The other vital skill is learning. Things keep changing. If you enjoy learning about cool new stuff you'll have no trouble staying employed. If you've written some non-trivial chunks of C/C++ and you have a CS degree from a decent school like Berkeley you'll do fine. Be good at your assigned tasks so you can get it done early and done well. (Try not to get involved in office politics if there is any.) This frees up time to think about cool stuff, whether that's free software or work-related extra credit.

    And don't forget there's life out there beyond software and work.

  • by mcrbids (148650) on Monday December 11, 2006 @01:28PM (#17196544) Journal
    My experience has been that you MUST teach yourself... especially if you work for the big cubicle farms. Teach yourself so you become better, so you keep your skills current, so you energize your imagination, and so you can go elsewhere when your employer enters the BRED ("Beancounters Rule Every Decision") Stage Of Atrophy.

    I don't know where the big cubicle farm comes into play, here. Working as an independent contractor has led me to the exact same conclusion. Always learn, ALWAYS teach yourself. It's pretty much ALWAYS worth it.

    And don't limit yourself to Comp Sci, either. For example, I'm currently training to be a private pilot. Why? I don't know, and never do. It's fun, I like to fly, and having more skills and experience has always paid me well. One of the best things you can do is to spend a few bux at the local Barnes and Nobles on a subject you know little about. B & N is a goldmine of business plans, technology information, and income opportunities!

    I've attended numerous business courses in salesmanship and capital investment. They've also served me well, and helped me identify a startup with real potential, and gave me the skills to sell my way into partial ownership of the company. (that's now growing by leaps and bounds)

    Another example - I did some research into using PHP as a scripting language for an SMTP daemon. I wanted to do some dynamic proxying that I didn't see elsewhere. I got it to work, using PHP as a script under xinet.d on Linux. Although that original business idea went nowhere, I used that very same software code to build a daemon that today transfers many gigabytes of data in a distributed software database, with about a thousand daily users.

    Having more saleable skills will always pay.
  • by SpinyNorman (33776) on Monday December 11, 2006 @01:30PM (#17196588)
    Well, I've been programming professionally for over 25 years, so ...

    The real skill in programming is knowing how to break down a complex project into suitable pieces - top down modular design. The skill is not just being able to do this at all for arbitrarily complex projects, but being able to do it well - to select a breakdown that will be easy to develop and maintain, easy to debug, easy to modify and extend.

    I really don't think there's any substitute for experience in learning this, since that's the only way it's really going to sink in and become second nature. The best thing you can do therefore is to practice, and push yourself with new challenges all the time. At work push to get on the most demanding projects, and out of work do hobbyist projects that push yourself too. When you switch jobs, don't shy away from switching industries and into new areas. You'll become a stronger programmer by being a generalist rather than a specialist, as long as there's also plenty of depth (don't skip around *too* fast).

    What you're really learning via experience is a set of design patterns and approaches, so that when you look at new problems they will intuitively fall apart into "obvious" breakdowns. Nowadays it's fashionable to read books on design patterns, and that can maybe help, but I'd tend so suggest a more back to basics approach of just paying attention to the interfaces between your modules... A good modular breakdown is one that results in modules that may have a fair degree of internal complexity (but not too much - break it down further), but have simple/thin external interfaces. An overly complex module interface is often a sign of choosing a sub-optimal modular breakdown (you've drawn the dividing lines in the wrong place). Good modular design will also hide as much internal design as possible to keep things simple and flexible - if you've kept the interface simple and abstract, then you have more flexibility to change the implemenation.
  • Advice (Score:2, Insightful)

    by clawhound (811481) on Monday December 11, 2006 @01:42PM (#17196770)
    College doesn't give you a career. Instead, college gives you the tools necessary to build a career in a specific field.

    You don't know everything. Nobody does. An education gives you grounding in many disciplines, but not mastery. Believe it or not, any undergraduate degree is a survey degree. It isn't specialized.

    My boss has a PhD in SQL. He teaches classes at universities. His students taught him how to better use different types of queries. They didn't teach him because he's dumb, but because nobody out there know everything, nor does anyone out there know all the tricks, nor does get all the possible implications of every technology all the time. Quite simply, there's a mindboggling mountain of information out there and you can't know it all.

    I know perl. Well, I know a slice of perl. It's a very useful slice. I use regular expressions to text mash and save myself huge slices of time converting documents. I don't nearly know everything about regular expressions. I also know some basic HTML, but I'm nowhere near being an expert. I know mediawiki format, but I'm not expert in everything that it can do. However, I have learned each well enough to custom convert HTML documents into mediawiki format and auto-tag most recurring vocabulary that needs tagging. Note that I don't know how to build an interpreted languages and I don't know how to set up mediawiki templates. I depend on others to know these things.

    That example above is the real world. I could choose any one of them, spend a year studying them, and still not know them in full detail.

    So, like folks say, pick a place and start. You will know some of what you need, but you will need to learn many new things, too. That's normal.
  • by Frankinmerth (869698) on Monday December 11, 2006 @01:46PM (#17196828)
    Learning how things work is one thing, and you'll learn how the relevant things work on the job. The real difference between school and the work day is people and process. When you're working for a company you have to deal with the tools that they use, the process (or lack thereof) that is in place, and the management structure that you will be forced to deal with day to day. These things make the difference from job to job and company to company. So being informed about how good companies run and what sorts of tools they use to do their jobs is useful. Often schools lack exposure to multiple development environments, revision and problem tracking solutions, and of course dealing with the business and sales forces that are often directly opposed to your opinions. This information might help you choose a good job over a poor one and, make no mistake, there is a difference. These days I think (as others have mentioned) that taking advantage of the wealth of open source projects out there is an excellent resource. Find one that is commercial level, not just a bunch of kids who want to do something cool. Something run by experienced professionals (who MIGHT be kids, it happens). Sign up and start taking on tasks and seeing how they actually keep the ship running. Get used to co-developing and merging code, documenting it for others to read, and testing in a different way than you might have on small projects in school. Keep in mind that each thing you check in ought to be as close to production quality as possible, and see how a large project can take a list of gazillions of problems and continue to chug away and produce releases. Learn how good projects are architected with growth in mind, but with concern for getting step 1 out the door before getting mired in step 2. The details fill themselves in, just get used to the environment. Oh, and more importantly, do this on a very part time level while working a junior position that pads your resumé(or while unemployed/at school). The rest of the time, go out and socialize and enjoy other hobbies. Don't burn out, and don't turn into a closet case, because nobody wants to work with uninteresting or antisocial people. I would always hire somebody smart but enjoyable who would go out for a beer with the team or help keep things friendly and loose at work over somebody who is much smarter but absolutely no fun to be around. There are places that hire purely on scores and grand ideas, but most business is a social endeavor. At any given job not everybody has to be a wizard (and somebody fresh out of school is not hired for their all-encompassing knowledge), in fact with too many chiefs nothing will ever get done and a business will tank. So you have plenty of time to learn while you work your way up, and lots of people to learn from. I see a lot of people giving you flack for coming out of school without a lot of knowledge. Well frankly most schools are not good for learning how everything works. There is too much out there for them to focus on how a NES emulator works. They are busy with fundamentals, with teaching you to work hard, and seeing if you can absorb and learn. Thats all a degree means. It means you can handle whats thrown at you, not that you already know how to do it.
  • by EraserMouseMan (847479) on Monday December 11, 2006 @01:59PM (#17197028)
    Unless you own your own company you will be a worker bee. You might work in a nicer hive. But you'll still be taking orders till you retire.

    I don't mean to bash you, man. But I realized this my sophomore year. All of the theoretical geniuses basically have to work for a company. They are energized by science, not business or other practical things. That's when I switched my minor to Business. I'd sit in the computer lab and think about which of my theoretical genius buddies I'd like to hire someday.

    Some of the brightest people I went to school with work for me now. I even had the most brilliant and respected CS college professor working for me during the summers. Don't want to be a worker bee? Then you've got to own your company. That's true freedom.
  • Re:Refund? (Score:5, Insightful)

    by Lord Ender (156273) on Monday December 11, 2006 @02:07PM (#17197162) Homepage
    I got a recent degree and know exactly how to start writing an emulator.

    At most schools, Computer Science is mostly the study of algorithms. My school, however, had a degree called "Computer Science and Engineering." In this program, students learned not only algorithms, but also digital logic, electronics, and computer architecture. Students had to design an entire computer using basic digital logic components (by first building multiplexers, decoders from and/or/not gates). Then we had to write an emulator for a simple computer. Finally, we wrote a compiler/linker for the emulator.

    FYI, the BSCS&E is a significantly harder program than the B.Arts in CS program. While we were taking extra physics and EE courses, the CS people were taking French, Theatre, and other easy courses that had real, live girls in them. We got the better education, sure, but I'm not sure it was worth it :-)
  • by jagdish (981925) on Monday December 11, 2006 @02:13PM (#17197270)
    Oh, by the way, go fuck yourself asshole.

    "The person who wrote that is dangerous. And this button-down, Oxford-cloth psycho might just snap, and then stalk from office to office with an Armalite AR-10 carbine gas-powered semi-automatic weapon, pumping round after round into colleagues and co-workers. This might be someone you've known for years. Someone very, very close to you."
  • Re:digg around (Score:2, Insightful)

    by painQuin (626852) <> on Monday December 11, 2006 @02:17PM (#17197320) Homepage
    I would go so far as to say that most experienced programmers teach beginner programmers not to use goto because of its potential for misuse (and breaking your code), but when used properly it can be incredibly powerful. The hard part is getting over the stigma and acknowledging that "Yes, this is where I should use goto."
  • by camperdave (969942) on Monday December 11, 2006 @02:25PM (#17197434) Journal
    One book you should definitely read is Writing Solid Code by Steve Maguire. It will help you train yourself to be aware of how bugs can creep into your programs, and what to do when you encounter them. Instead of just blundering ahead with a fix, you should be asking yourself "How could I have prevented this bug?" and "How could I have automatically detected this bug?".

    You may also want to read is The Elements of Programming Style by Kernighan and Plauger. I've only skimmed through it, but it talks about writing code so that its function is obvious to other programmers. (Trust me, few people can look back on code they wrote five years ago and remember why they wrote a particular routine that way.)

    Another book I would recommend is Structured Computer Organization by Andrew Tanenbaum. It will take you from circuits and logic gates, through how a CPU works, to how Operating Systems work.

    The only other recommendation I would make, is to become an organized note taker. The top programmer in one of the companies I worked for was such a person. If there was a question with the way something worked, he could pull out a notepad, flip through a few pages, and tell you what issues he was dealing with in the code, and why he made certain design choices. If he got an error message, he would write it down, and what steps he used to correct it.

    I'm sure others have mentioned continually educating and upgrading yourself, and that an IT career these days means having lots of short term jobs, rather than a single lifelong job, joining clubs and associations, etc. The only thing I would add to that is Practice, Practice, Practice. Write code until it is second nature to bang out high quality code.
  • by bryz (730558) on Monday December 11, 2006 @02:49PM (#17197762) Homepage
    I understand your point, but this really doesn't help the original poster.

    First, he just got a job and moving to another company right away is probably not the best available option.

    Second, if he's interested in pursuing hobby like interests like game emulators, there probably aren't many companies out there doing advanced work in that field.

    While ideally, it would be great for him to learn directly from the best in the field, realistically, this isn't an option. Therefore, the best solution for this recent college grad who is completely lost and wants to start digging today is probably to use the internet.

    I'm not recommending that he does a copy and paste job, but even from poor examples I'm sure he'll be able to learn something. And also there is benefit from reading bad code as well as good code.

  • by Tired and Emotional (750842) on Monday December 11, 2006 @03:19PM (#17198188)
    The trick is to avoid 1 year of experience 10 times over.

    To do that you have to always look for a challenge. When you get to saying "I can do this standing on one ear" its time to go do something you don't think you can handle.

    As a beginner though, the big thing to learn is that software experience doesn't scale. Writing a 100 line program does not prepare you to write a 1000 line program which is nothing like writing a 10,000 line program and when you get past about 20,000 lines its totally different because you can't keep it all in your head at once.

    The next most important thing after learning to write bigger and bigger programs is learning to not write programs. This comes in two flavors. Some tasks can be reduced to a specification and a generator. Some tasks should not be automated at all because they are wrong - the first step is to work out what the task really is or should be, not to implement what its claimed to be.

    Actually, that's a good principle in general - and one I have never seen a graduate understand. Programming is gathering of knowledge and codifying it. On all but trivial projects you won't have all the knowledge at the start and you can only get it by starting to implement the system - the system is an experiment.

    So early in the project the most important thing is to try to work out what are the most important unknowns and what would be the worst surprizes so you can go after these early.

    And while programming it is important to build in adaptability so you can react to new information. Make your system as generalized as possible, even at the expense of some performance and extra coding at first - tuning should be done late.

  • Re:Write new code (Score:2, Insightful)

    by Maltheus (248271) on Monday December 11, 2006 @04:03PM (#17198810)
    This poster has it right. Reading code isn't going to get you far and it isn't much fun. Spend a weekend screwing around on your computer and make note of each time you thought it'd be great if X software did Y. Then write your own. Write something that would be useful to you.

    If a piece of code seems like a hack to get something to work, then fix it. Make it elegant. While writing it, you'll probably code yourself into several messy corners where you know it's not right (even if it works) but you're not sure what might be better. These pieces of code will provide your greatest learning experience, provided you do whatever is necessary to make them better. That includes rewriting your project from scratch, if needed. Rewriting something from scratch goes a lot faster than it did writing it the first time, and it usually ends up saving more time in the long run. I find it's the best way to refine your technique.
  • by Wrangler (219457) on Monday December 11, 2006 @04:22PM (#17199072)
    Mea culpa - /me graduated from college with a computer science degree in the 20th Century.

    Second, an observation - you went to a college with a crappy CS curriculum. If you didn't take at *least* half a dozen courses programming multiple assignments in at least half a dozen languages, you got ripped off buddy. When I went through my undergrad, I wrote programming assignments in ALGOL, BASIC, COBOL, FORTRAN, IBM assembler, LISP, PASCAL, PL/1, and SNOBOL. Now, that's an education!

    I can teach you how to program in under one minute. Don't believe me? Here it is - start your timer.

    There are three kinds of computer code - straight code, iterative code,
    and conditional code. Straight code is what it sounds like, serial
    instructions - do this, do that, in a particular order. Iterative code
    is repetition - do this, then repeat the same instructions until or
    unless some condition changes. Conditional code is a single or multiple
    either-or construct - if this, do something, otherwise do something
    else. Of course each of these three types of code can be combined.


    Oh, did I neglect to mention the *syntax* of the programming language?

    Yeah, see, that's why they have O'Reilly books and the Internet and ... college classes to teach you programming. Because it's the nuances of the particular programming language, things like how pointers work in C or how you have to align memory data for assembler instructions, those are the bits of knowledge that constitute the essence of programming a

    Contrary to popular belief (as I just illustrated a couple of paragraphs ago), it's not the structured paradigm or the OOP paradigm that defines "how to program". Rather your expert PERL coder has the in depth understanding of the PERL programming language that allows them to craft elegant code, while your novice PERL coder does not know how to take advantage of the language and will write less efficient code. The same applies to any programming language - an understanding of the language (and to a lesser extend an understanding of how the computer processes the instructions (which is how printf format string vulnerabilities were identified) is what allows a programmer to instruct the computer to do what the programmers desires.

    Just like a natural language, you're communicating with a recipient, and the accuracy of your communication is directly proportional to your grasp of the language that you are using, not to your recipient's ability to grasp what you're trying to communicate.

    So, advice for programmers - you need to do two things, in order. First, research which programming languages are most prevalent in the field where you wish to work. Second, learn to program in that language backwards and forwards.

    For example, if you want to work in banking or credit card processing you might consider COBOL (Happy B'Day grace Hopper, you miserable old skank) and mainframe IBM assembler. If you want to do k3wl K-R4d bleeding edge work at SUN, start studying JAVA (and pay particular attention to multiple inheritance). If you're going to do funky ASP work in PERL, read the Camel book and the PERL man pages and as much PERL code as you can find.

    Above all, start coding and code until it hurts. Because you can bet that at least one person interviewing you for your job has been coding for a long time and understands the pitfalls of the particular language, and wants to hire someone else who understands and can work in that language.

  • by h4ck7h3p14n37 (926070) on Monday December 11, 2006 @09:17PM (#17202646) Homepage
    While I do like your comment overall, I have written an emulator while an undergrad and would never suggest that someone begin learning about them by reverse engineering something as complex as a NES emulator. ari1981 didn't mention what material he covered in school, only that it was theoretical so that makes it a bit difficult to determine what areas of knowledge need some improvement. Actually, knowing computional theory is probably half of the battle when it comes to programming.

    Writing in a programming language is exactly like writing in any other language. As a neophyte, you're constantly consulting your textbook for the proper verb tense to use, you're looking up simple nouns, etc. Eventually you get the grammar down and have built up enough of a vocabulary that you only have to consult the dictionary once in awhile. Eventually you rarely have to look words up and can start focusing on things like elegant sentence structure.

    Here's a list of what I considered to be essential areas of learning with regards to computer science. UNIX was mentioned in the article, so I'll include that as well:

    Here's a list of general knowledge:

    • A procedural programming language: something like Pascal, Fortran, C or Perl
    • A functional programming language: traditionally Lisp, but Erlang's cool too!
    • An object oriented programming language: Eiffel, Smalltalk, Java, C++ (really a hybrid)
    • Data structures: lists, heaps, stacks, trees, dictionaries, etc.
    • Algorithms: complexity, sorting, graph traversal, etc.
    • Theory of computation: Turing machines, deterministic and non-deterministic finite automata, context-free grammars, etc.
    • Operating systems: job scheduling, filesystems, memory management, shared resources. I really liked "Operating System Concepts" by Silbershatz and Gavin.
    • Computer architecture: different types of machines, cpu pipelining, memory cache design, application binary interfaces, etc. "Computer Architecture: A Quantitative Approach" is THE book for this.
    • Software design: I can't recommend anything specific, but have noticed that many University courses do a really bad job of covering this (mine did).

    And here's a list of UNIX specific knowledge:

    • Layout of the system: where files are and what they're used for
    • Design and implementation: I really like the Daemon (Design and Implementation of the 4.4 BSD Operating System) book for this
    • Systems programming: IPC, networking, etc; get Richard Stevens' books
    And some more:
    • Revision control systems
    • Build systems
    • Debugging/test frameworks

    I agree that one should simply explore what they're most interested in, but an emulator is a lot to bite off if you don't know the difference between little and big-endian, RISC versus CISC architectures, and ABI's.

FORTUNE'S FUN FACTS TO KNOW AND TELL: #44 Zebras are colored with dark stripes on a light background.