Slashdot Mirror
Advice For Programmers Right Out of School
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?"
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?
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
My work here is dung.
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.
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:
http://www.obelisk.demon.co.uk/6502/
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: 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.
Javascript + Nintendo DSi = DSiCade
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.
Rich And Stupid is not so bad as Working For Rich And Stupid.
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.
www.jmagar.com
-
" 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.
"If you make people think they're thinking, they'll love you; But if you really make them think, they'll hate you." - DM
College teaches you how to learn. Once you realize that, your education truly begins.
Weaselmancer
rediculous.
I know a site with lots of great snippets to learn from!
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.
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.
SIGSEGV caught, terminating
wait... not that kind of sig.
You, sir, must not be a true programmer. If you were, you would know that goto has long been considered evil. Instead, you should make sourceforge into a function, and call it as such: sourceforge().