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?"
digg around (Score:2, Informative)
Starting is HARD. (Score:5, Informative)
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.
Invest in yourself. Assume no one else will. (Score:5, Informative)
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.
Re:What school did you go to? (Score:5, Informative)
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.
Re:My Advice (Though You May Not Agree) (Score:3, Informative)
Yeah, we got yer advice right here! (Score:5, Informative)
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:
- 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.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.
Watch and learn from another geek (ShowMeDo) (Score:2, Informative)
A great way to learn is to watch somebody else, that's why Kyran and I founded ShowMeDo.com [showmedo.com] 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)
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)
How an emulator works (Score:1, Informative)
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)
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 [37signals.com] 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 [pmi.org] to understand "work units" and "earned value" -- understand how to get work done and measure it.
Re:From the Ground Up? (Score:3, Informative)
Re:From the Ground Up? (Score:3, Informative)
Re:My Advice (Though You May Not Agree) (Score:3, Informative)
A more appropriate name would be SDS; 'Standard Diagram Set'.