Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Programming IT Technology

Advice For Programmers Right Out of School 469

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:
  • digg around (Score:2, Informative)

    by jrwr00 ( 1035020 ) <jrwr00&gmail,com> on Monday December 11, 2006 @11:29AM (#17194682) Homepage
    Goto source forge and have a field day! you can find many projects with tons of different ways to do different things. just drive into the code of ZSNES or Nethack and explore the code, and see how they did it
  • Starting is HARD. (Score:5, Informative)

    by xtal ( 49134 ) on Monday December 11, 2006 @11:33AM (#17194738)
    An open source project is a good idea as a starting point. Pick away at something that already works.

    Where that isn't an option; I've always turned to O'Reilly books, and online tutorials to learn some new skills. I've written some tutorials for people who are interested in getting started with embedded electronics, for example. It's not hard to do, but you need to know about a half dozen things before you can get started.

    I suspect you're either giving up too easy, or not looking online enough, or in the wrong places. For console emulation, there's a LOT of documentaion in the source code for MAME, and I am sure the others are similar.

    Most of the people who are doing complicated OS programming have 10, 15, or even 20+ years of hacking away. Spending thousands and thousands of hours in front of a computer helps. Unless it's spent playing WoW, maybe. :)
  • by Dystopian Rebel ( 714995 ) * on Monday December 11, 2006 @11:37AM (#17194808) Journal
    Congratulations on earning your degree.

    An entire generation of creative software people who had great ideas and deaf employers grew sick of their cubicles and started the open-source software revolution. They wanted to learn stuff and do stuff, just like you do.

    Grab the code, read it, mess with it. Invest in yourself and assume no one else will.

    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.

    BRED means that your employer is unlikely to pay for you to learn anything useful, especially not during the sunny hours when their BMWs and Porsches are in the parking lot. BRED means that good ideas die unless you happen to drink whisky with the CEO once a week.

    Cowardly employees and consitutionally cheerful employees are easier to flog and much less frightening and expensive than people who want their employer to invest in them. People who have the latest skills aren't chained heavily enough. And when the expenses grow and the balance-sheets and Powerpoint slides don't show the Beancounters at the top any benefit ("any chance of getting more stock options"), you can bet that your Red Swingline Stapler is going to Bangalore.
  • by mbrod ( 19122 ) on Monday December 11, 2006 @11:53AM (#17195102) Homepage Journal

    I have to wonder about the quality of your degree..., seriously.
    I don't.

    What large software project doesn't already start with a huge number of the pieces being already written? Nearly all modern software is taking building blocks, tools, libraries that exist or are bought and then using them to get whatever task done.

    The vast majority of work is done this way so a program concentrating on that type of work would not be as relevant. Very little work is done actually starting from scratch on anything.

    Like others have pointed out the best way to learn these other areas is with OSS projects and you don't need to pay a college to teach you how to get involved with them. You can do them on your own time.
  • by Belial6 ( 794905 ) on Monday December 11, 2006 @12:22PM (#17195530)
    This is very good advice. As for writing your emulator, the NES is the perfect emulator to start with. The design is simple, and the system is extremely well documented. Start searching the web and you will find every detail necessary to write a NES emulator, including several open source projects written in various languages.
  • by inviolet ( 797804 ) <> on Monday December 11, 2006 @12:29PM (#17195662) Journal

    As quickly as you can, get in a position of supporting your own code when it goes out into the world onto customer machines. This will teach you a profoundly important set of convictions that CS professors -- having never done the aforementioned -- are clueless about:

    • Calls outside your own module (OS APIs, etc.) always fail, and so your code should always expect as much. You can tell a novice programmer's code because it makes SDK calls without checking the return codes.
    • Error messages should be in plain Enlish and contain programmer-level diagnostic information and suggest to the user the most likely cause so that he can maybe fix it himself:
      • bad: "Error: operation failed."
      • bad: "Error 0x8009000b during update!"
      • good: "Error: the mailslot update failed, probably because the mailbox is locked by another process; please contact technical support. (COM synchronize call returned 0x8009000b)"
      Every low-quality error message equals ten calls to tech-support and probably two days of some support programmer's time and remaining hair pigmentation.
    • All of your programs should have a logger facility that can create round-the-clock logfiles for diagnosing those "It happens only at 3am, after it's been running 16 hours straight" problems.

    Most programmers never acquire these convictions, because they never retain ownership of their code long enough to see the patterns that occur during field support. Hopefully you will be different... because honestly, in the long run it's easier to write supportable code than it is to have to check under your car for bombs every morning.

  • by ianOz ( 988378 ) on Monday December 11, 2006 @01:04PM (#17196188) Homepage

    A great way to learn is to watch somebody else, that's why Kyran and I founded [] a year ago. We host tutorial videos (to date all 104 are free) made by our users, so you can watch a fellow geek introducing a subject.

    We have videos for Python, Java, Ruby, Perl, a bunch of miscellaneous utilities and we've just started accepting videos on graphics programs (Blender 3D and Flash 8 so far). We'd love to have more submissions, naturally :-)

    We put source code into the wiki and we'll begin to push the forums soon so that fellow learners can help each other to progress. If you like the videos then don't forget to leave a comment thanking authors for their time!

    Both Kyran and I realised that it seems odd that we learn in seclusion via books (and hacking around, of course), yet we can learn so much more when we're with someone who can answer our questions. We can't give you a personal expert, but we can let experts share their knowledge with you. Our ears are always open for feedback, we'd love to build a better learning environment.

  • Re:Write new code (Score:5, Informative)

    by Creepy ( 93888 ) on Monday December 11, 2006 @01:10PM (#17196260) Journal
    I think you missed two key points:
    Pick something with realistic goals for whatever sized team you have (or self) and set goals
    Design your work first

    If you don't do those, you'll probably never learn to finish code. Setting goals with a team usually needs to be done based on time and skill levels of members. If it's just you, set goals for yourself and stick with them as best as possible. Don't worry too much about missing a date as long as you made progress towards your goal (but make sure to set a new goal).

    Also don't be afraid to axe a project if you have to. I had a flight sim with some beautiful code in it (the blitter was fantastic... too bad blitters died with that era of hardware) and over a year of work and I killed the project even though completion was probably only a few months away. Why? because it had a problem at the core of the engine that was unfix-able and needed to be recoded from scratch to boost it to optimal framerates (specifically, I used virtuals at a low level not knowing that they have an expensive look-up table). I also had bought my first Voodoo card by that point and knew that was the future, not painter's algorithm and blitters. As sad as I was killing what I hoped would be a shareware quality flight sim, I learned so many lessons that it was worth the time spent.

    I can't tell you how many kids I've talked to that want to make a commercial quality MMORPG or a 3D shooter in a few months...
  • Re:Write new code (Score:5, Informative)

    by twiddlingbits ( 707452 ) on Monday December 11, 2006 @01:12PM (#17196302)
    I got to disagree with this "Also don't allow your self to become too specialized, you want a broad skill-set. Excessive specialization is leads to trouble." This is EXACTLY what I have done in my 24 yrs in IT and Software by working at a number of places and a lot of contracts. What employers want now IS Specialization, say .NET with C# and SQL and Exchange, etc. or J2EE with a certain Java server and certain appplication types. I see a LOT less jobs for folks like me who know software, hardware, networks, Project Management, Sales, different methodologies, 25yrs of IT technologies and I also hold an Advanced degree. I suppose my downfall is I'm not a Java or .Net "pro" as I was in Management and Architecture when these technolgies were emerging and never practiced them. I would say find a solid progrgramming niche and MASTER it but beware of the things that are coming to replace what you know. Today's hot stuff is tomorrow's warmed over crap.
  • by Anonymous Coward on Monday December 11, 2006 @01:20PM (#17196442)
    It may sound like voodoo at first, but it's actually quite simple (assuming the machine you're emulating is well documented!) but time consuming to get right.

    Take a CPU emulator for instance with some code that runs on it. You have to have a very good knowledge of the opcodes of the CPU you are emulating (say, a 6502 for example). You need to know how many cycles each instruction takes, what arguments it accepts, what the output is, how many bytes the instruction is and the size of the arguments (can be variable depending on the instruction code), what the registers and CPU flags will contain after each instruction, etc. In short, you need to have detailed documentation on that CPU to understand it. If what you're emulating isn't completely documented, don't waste your time. Wait until you're far more experienced.

    So, basically, your program will sort of work like this:

    1. Read a byte (typically) of code from the program to be emulated.
    2. Use a table lookup to determine what that instruction is.
    3. Read X number of bytes (based on what was determined in step 2) that make up the operand.
    4. Jump to the handler for that instruction, which will place a value in a memory location, do a mathematical operation, etc. Whatever it takes to duplicate the functionality of the original CPU instruction. This is the meat of your emulator and the tough part, especially if you want it to be cycle-exact. Handling the storing, modification, and retrieval of variables in memory is a big part of this.
    5. Increment the virtual instruction pointer and read the next opcode in the program.

    Extremely simple overview, but if you do some research on emulation and virtual machines, you'll find out a lot more. It's quite interesting!
  • One word: Deadlines (Score:3, Informative)

    by unfortunateson ( 527551 ) on Monday December 11, 2006 @02:06PM (#17197146) Journal
    You'll never get anything done "for real" until it's important. Whether it's a personal project like the console emulator you mentioned, or a for-hire piece of work, or a chunk of Mozilla you really care about, you'll do it when you have to.

    26 years ago, I did part-time work on a PDP-11-based system as I entered college. I found that in my classes, I'd write a 1000-line program that produced ten lines of code... and at work, I'd have a 1000-line program that produces 10,000 pages of output a month, on a much more constrained system. And my 1000 lines of code were equivalent to 3000-line versions by other students (and yes, I had documentation in my code)

    Constraints make you work better. Read 37Signals' blog [] to find out how to work with less.

    Big projects happen in little steps. Take a project management class -- look at the Project Management Institute [] to understand "work units" and "earned value" -- understand how to get work done and measure it.
  • by Marlow the Irelander ( 928776 ) <> on Monday December 11, 2006 @04:24PM (#17199104) Homepage
    I believe that it comes from an example in the original K&R "The C Programming Language". Wikipedia [] shows that I'm mostly right, but they stole it from one of K's memos.
  • by Fulcrum of Evil ( 560260 ) on Monday December 11, 2006 @06:25PM (#17200780)
    Even HelloWorld, as generally written, depends on a lot of code already being there - printf and the various low level io routines aren't particularly complicated, but they are a pain in the ass if you have to write them yourself.
  • by jez9999 ( 618189 ) on Tuesday December 12, 2006 @06:05AM (#17205632) Homepage Journal
    I also remind anyone that's learning UML not to get confused / misled by the name. It's not unified, and it's not a language. It is for modeling.

    A more appropriate name would be SDS; 'Standard Diagram Set'.

System checkpoint complete.